1 1 “Secure the High Ground” Jeff Craver Project Manager Space and Missile Defense Technical Center Jeff Craver Project Manager.

Slides:



Advertisements
Similar presentations
Willie J. Fitzpatrick, PhD Chief, Aviation Division
Advertisements

Technology Module: Technology Readiness Levels (TRLs) Space Systems Engineering, version 1.0 SOURCE INFORMATION: The material contained in this lecture.
Technology readiness levels in a nutshell
What Is A Technical Readiness Level and How Is It Used?
Technology Readiness (TR)
© 2009 The MITRE Corporation. All rights Reserved. Evolutionary Strategies for the Development of a SOA-Enabled USMC Enterprise Mohamed Hussein, Ph.D.
DISTRIBUTION A.: Approved for public release; distribution unlimited. SMDC #3139. DTRA #NT Breakthroughs in Applying Systems Engineering.
Aerospace Systems Engineering
“Common Process for Developing Briefings for Major Decision Points” INSTRUCTIONS Provide Feedback via to: Lois Harper PEO C4I and Space
Systems Engineering in a System of Systems Context
DoD Systems and Software Engineering A Strategy for Enhanced Systems Engineering Kristen Baldwin Acting Director, Systems and Software Engineering Office.
1 Introduction to System Engineering G. Nacouzi ME 155B.
Chapter 5: Project Scope Management
Development Processes and Product Planning
Certified Business Process Professional (CBPP®) Exam Overview
IS&T Project Management: How to Engage the Customer September 27, 2005.
What are MRLs ? Alfred W. Clark Dawnbreaker, Inc.
May 4, Establish an Acquisition process that produces: Required, Affordable, Timely Products Big “A” Acquisition Resources Acquisition Requirements.
Developing Enterprise Architecture
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
N By: Md Rezaul Huda Reza n
Best Practices in Defense Technology Development and Technology Maturity Assessments Systems & Software Technology Conference (SSTC) 28 April 2010.
UNCLASSIFIED Joint and Coalition Warfighting Mr. John Vinett March 2012 Technical Baseline Capability.
Software System Engineering: A tutorial
The Challenge of IT-Business Alignment
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
Recap from last week Understand organizations, including the four frames, organizational structures. Explain why stakeholder management and top management.
GBA IT Project Management Final Project - Establishment of a Project Management Management Office 10 July, 2003.
Software Engineering Lecture # 17
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
MD Digital Government Summit, June 26, Maryland Project Management Oversight & System Development Life Cycle (SDLC) Robert Krauss MD Digital Government.
Andrew Faulkner1 Technology Readiness Levels 4 th SKADS Workshop, Lisbon Technology Readiness Levels TRLs Andrew Faulkner.
Chapter 7: A Summary of Tools Focus: This chapter outlines all the customer-driven project management tools and techniques and provides recommendations.
CHECKPOINTS OF THE PROCESS Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle: 1)Major milestones,
Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger September 29, 2009.
The Center for Space Research Programs CSRP Technology Readiness Level.
I n t e g r i t y - S e r v i c e - E x c e l l e n c e Business & Enterprise Systems The Integrated Master Plan (IMP) and the Integrated Master Schedule.
Microsoft Office Project 2003: Selling EPM in your Organization Matt Wilson Business Solutions Specialist LMR Solutions.
Develop Project Charter
Practical Investment Assurance Framework PIAF Copyright © 2009 Group Joy Pty. Ltd. All rights reserved. Recommended for C- Level Executives.
1 MRL Assist Tool Website Access the MRL Assist Tool at
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
Lecture 2.1b: DoD Acquisition Process (SEF Ch 2)
Simple rules to follow when creating the business plan.
Validate Scope What we have: Requirement Traceability Matrix Verified Deliverables What we do: Inspection What we get: Accepted Deliverables.
SOLUTION What kind of plan do we need? How will we know if the work is on track to be done? How quickly can we get this done? How long will this work take.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
MB6025-MB7226 TECHNOLOGY COMMERCIALIZATION
Assessment of Fusion Development Path: Initial Results of the ARIES “Pathways” Program Farrokh Najmabadi UC San Diego ANS 18 th Topical Meeting on the.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
Horizon 2020 – 2016 Transport Call
Association of Enterprise Architects International Committee on Enterprise Architecture Standards Jan 23, Collaborative Expedition Workshop #57aeajournal.org.
Info-Tech Research Group1 Manage IT Budgets & Cost World Class Operations - Impact Workshop.
What has been accomplished at the end of MSD 1 & 2?
Cross-Domain Semantic Interoperability ~ Via Common Upper Ontologies ~ Presentation to: Expedition Workshop #53 15 Aug 2006 James Schoening
Enterprise Architectures Course Code : CPIS-352 King Abdul Aziz University, Jeddah Saudi Arabia.
Dr. Thomas D. Fiorino November 2002
Introduction to Project Management
Supportability Design Considerations
Technology Readiness Assessment (TRA)
Technology Program Management Model (TPMM)
Milestone A to Milestone B Requirements Management Activities
Identify the Risk of Not Doing BA
Hyper-V Cloud Proof of Concept Kickoff Meeting <Customer Name>
Concept Idea Title Summary of the effort to include:
Introduction to Tech Communication & Project Management Arthur C.M. Chen , Rm
Enterprise Architecture at Penn State
What Is A Technical Readiness Level and How Is It Used?
Presentation transcript:

1 1 “Secure the High Ground” Jeff Craver Project Manager Space and Missile Defense Technical Center Jeff Craver Project Manager Space and Missile Defense Technical Center UNCLASSIFIED Technology Program Management Model (TPMM) Executive Overview A Systems-Engineering Approach to Technology Development and Program Management Technology Program Management Model (TPMM) Executive Overview A Systems-Engineering Approach to Technology Development and Program Management Mike Ellis TPMM Development Manager Dynetics, Inc. Mike Ellis TPMM Development Manager Dynetics, Inc.

2 2 “Secure the High Ground” Introduction TPMM V2 applies a systems engineering methodology to Technology Program Management This presentation will provide a high-level overview of how a model like the TPMM can provide the Defense S&T community as a whole with the following benefits: Re-Introduces Systems Engineering Facilitates Stakeholder Alignment Better Insight into Program Execution Reliable Management Decisions Improves Technology Transition

3 3 “Secure the High Ground” Challenge of Every S&T and Acquisition Organization Effectively managing technology development Programmatic problems Lack of Systems Engineering Principles Successfully transitioning technologies Transition not considered as part of Tech Dev Lack of Customer/User identification/involvement

4 4 “Secure the High Ground” Quantifying the Effects of Immature Technologies According to a GAO review in 2005 of 54 DoD programs:  Only 15% of programs began System Design Decision [post MS B] with mature technology (TRL 7) Programs that attempted to integrate with immature technologies averaged 41% cost growth and a 13 month schedule delay  At Critical Design Review, 58% of programs demonstrated design instability (< 90% drawings releasable) Design stability not achievable with immature technologies Programs without stable designs at CDR averaged 46% cost growth and a 29 month schedule delay Source: Defense Acquisitions: Assessments of Selected Major Weapon Programs, GAO , March 2005

5 5 “Secure the High Ground” 5 Reasons Why This Happens Doctrine Promotes delay The DoD 5000 doesn’t call for the first Assessment of the technology until MS- B (too late in the process to have any real effect on an immature technology) Predisposition of Viewpoints Users know the requirements, Acquisition Managers know how to build things, and Technology Developers know how to invent. A Forcing Function is needed to effectively cross those boundaries Communication Breakdown Tech solutions selected to fill gaps need continual re-alignment to ensure development is on schedule and that the “right” problem is still being solved Culture Within the Technology Development Community Tradition of Invention and scientific endeavor in the Technology Community contributes to a lack of Transition Focus Interpretation Wide Enough to Drive a Humvee Through TRL definitions are vague and sometimes too subjective which can lead to more questions than answers. A System Engineering and Programmatic-based TRL criteria set needs to be applied as a standard earlier in the process.

6 6 “Secure the High Ground” DoD 5000 Metric  Technology Readiness Assessment (TRAs) - Required at MS B  TRAs using Technology Readiness Levels (TRLs) First TRA Requirement TRA 1 - Doctrine

7 7 “Secure the High Ground” Perspectives USER Threat Driven Soldier-Proof Fieldable Meets Mission Needs DOTMLPFDOTMLPF I’m governed by the JCIDS Hey Buddy - I OWN The Requirements! I Want it All!! I Want it Cheap! I Want it Now! Gotta be small, lightweight, and 99.99% reliable PM Value Added Capability Probability of Success Acquisition Strategy Budget (LLC/POM) Schedule - WBS The System “ approach” My prime can do that!! Your next chance for funding is 5 years down the road – stud! I NEED a REQUIRMENT (CDD)! You forgot about the “illities”!!! I am governed by DoD S&T If you “Push” long enough – they will come! You don’t understand - This project is different from everyone else S&T does not require a process – I have been doing it for years Customer role is to integrate Technical “break-thru” Performance Goals Risk Cost Estimate. Program Plan Build a prototype 2 - Predisposition

8 8 “Secure the High Ground” Aligning Technology with the Acquisition DoD 5000 MS’s 3 - Communication

9 9 “Secure the High Ground” Transition Management Technology Management Transitioning Technology Technology Management vs. Transition Management Typical Paradigm Transition an afterthought Technologist still tinkering Not knowing when you’re finished Not knowing when technology is needed 4 - Culture

10 “Secure the High Ground” Lowest level of technology readiness. Scientific research begins to be translated into technology’s basic properties. Invention begins. Once basic principles are observed, practical applications can be invented. The application is speculative and there is no proof or detailed analysis to support the assumption. Examples are still limited to paper studies. Active research and development is initiated. This includes analytical studies and laboratory studies to physically validate analytical predictions of separate elements of the technology. Examples include components that are not yet integrated or representative. Basic technological components are integrated to establish that the pieces will work together. This is relatively “low fidelity” compared to the eventual system. Examples include integration of “ad hoc” hardware in a laboratory. Fidelity of breadboard technology increases significantly. The basic technological components are integrated with reasonably realistic supporting elements so that the technology can be tested in simulated environment. Examples include “high fidelity” laboratory integration of components. Representative model or prototype system, which is well beyond the breadboard tested for level 5, is tested in a relevant environment. Represents a major step up in a technology’s demonstrated readiness. Examples include testing a prototype in a high fidelity laboratory environment or in simulated operational environment. Prototype near or at planned operational system. Represents a major step up from level 6, requiring the demonstration of an actual system prototype in an operational environment. Examples include testing the prototype in a test bed aircraft. Technology has been proven to work in its final form and under expected conditions. In almost all cases, this level represents the end of true system development. Examples include developmental test and evaluation of the system in its intended weapon system to determine if it meets design specs. Actual application of the technology in its final form and under mission conditions, such as those encountered in operational test and evaluation. Examples include using the system under operational mission conditions. 1. Basic principles observed and reported. 2. Technology concept and/or application formulated. 3. Analytical and experimental critical function and/or characteristic proof of concept. 4. Component and/or breadboard validation in laboratory environment. 5. Component and/or breadboard validation in relevant environment. 6. System/subsystem model or prototype demonstration in a relevant environment. 7. System prototype demonstration in an operational environment. 8. Actual system completed and qualified through test and demonstration. 9. Actual system proven through successful mission operations. 1. Basic principles observed and reported. 2. Technology concept and/or application formulated. 3. Analytical and experimental critical function and/or characteristic proof of concept. 4. Component and/or breadboard validation in laboratory environment. 5. Component and/or breadboard validation in relevant environment. 6. System/subsystem model or prototype demonstration in a relevant environment. 7. System prototype demonstration in an operational environment. 8. Actual system completed and qualified through test and demonstration. 9. Actual system proven through successful mission operations. When should I know what the requirements for the technology are? When should I know who my Customer is? What Programmatic & System Engineering tasks should be performed during each Stage of Development? How will my progress be measured? What are the criteria for completing a TRL? What is the definition of a success? At what point will the technology be transitioned to a Customer? Technology Readiness Levels DoD R In what way will this technology Add Value to the End User? 5 - Subjective

11 “Secure the High Ground” Quantifying the Effects of Immature Technologies According to a GAO review of 54 DoD programs:  Only 15% of programs began System Design Decision [post MS B] with mature technology (TRL 7) Programs that attempted to integrate with immature technologies averaged 41% cost growth and a 13 month schedule delay  At Critical Design Review, 58% of programs demonstrated design instability (< 90% drawings releasable) Design stability not achievable with immature technologies Programs without stable designs at CDR averaged 46% cost growth and a 29 month schedule delay Source: Defense Acquisitions: Assessments of Selected Major Weapon Programs, GAO , March 2005 A System Engineering and Programmatic-based TRL criteria set needs to be applied as a standard earlier in the process.

12 “Secure the High Ground” TRL 3 4. Component and/or breadboard validation in laboratory environment 5. Component and/or breadboard validation in relevant environment 6. System/ subsystem model or prototype demonstration in relevant environment TRL 4TRL 5TRL 6 1. Basic principles observed & reported 2. Technology concept and/or application formulated 3. Analytical and experimental critical function and/or characteristic proof of concept TRL 1TRL 2 MS B Technology Development PhaseConcept Refinement Phase MS A CD TPMM Criteria Discovery Develop an Idea Based on Threat, need, User Rqmt, Other Identify Pertinent Military Application & a Potential Customer(s) Formulation Develop a Concept Conduct Trade Studies Perform Military Utility Analysis Perform Paper Studies Identify specific customer(s) Analysis of Alternatives Proof of Concept and approach Develop General Technical Requirements ID cross technologies Develop Draft Tech Development Strategy TTA - Interest Refinement Demonstrate Key Technologies Work Together Refine Requirements System Eng Plan Update Tech Development Strategy TTA –Intent Development Demonstrate Components Work With/as System Finalize Requirements Develop Transition Plan and Gain Customer Approval Demonstration Transition Demonstrate Prototype Ready for Operations Demonstrate Increased Capabilities Develop Transition Agreement Acquisition Strategy TTA – Commitment Aligning TRLs & DoD 5000 Reduces Subjectivity

13 “Secure the High Ground” Alignment Mechanisms TPMM defines the process and transition mechanisms to help tech programs align with Acquisition Milestones Alignment Mechanisms Facilitate Effective Communication

14 “Secure the High Ground” Integration & Qualification Understand User Need, Develop/Identify Operational Requirements Identify the path ahead in a TRL Roadmap for Technology Development Prove the selected Technology fulfills the concept and Identify User/s Develop and execute a plan for applying the selected Technology to the identified need Support selecting the technology from Analysis of Alternatives Perform AoA in a laboratory environment Develop Technology Concept and Describe the Problem Delineate the concept’s feasibility to be solved technically Formulate/Design a methodology to evaluate Technology Alternatives Systems Engineering Design Engineering Feasibility FormulationProof of Concept TRL 1TRL 2TRL 3 User Need Initial Operational Requirements Prelim Concept Description Initial Technical Problem Feasibility Study AoA/Formulation Plan Proof of Concept Report Draft TDS Initial Technology Transition Agreement Proof of Concept Plan Lab Design Tech Alternatives Models Breadboard Laboratory Environment Test results Formulation AoA Findings TPMM Recommended Documentation Decomposition & Design Buede, The Engineering Design of Systems, 2000 TPMM and the Systems Engineering “V” in TRL 1-3

15 “Secure the High Ground” Integration & Qualification Understand User Requirements, Develop System Concept and Lab Validation Plan Demonstrate and Validate System to User validation Plan Integrate System and Perform System Verification to Performance Specifications Assemble CIs and Perform CI Verification to CI “Design-to” Specifications Inspect to “Build-to” Documentation Fab Assemble and Code to “Build-to” Documentation Develop System Performance Specification And Relevant Environment Validation Plan Expand Performance Specifications into CI “Design-to” Specifications And CI Verification Plan Evolve “Design-to” Specifications into “Build-to” Documentation And Inspection Plan Systems Engineering Design Engineering Refinement Development Demonstration/ Transition TRL 3TRL 4TRL 5TRL 6 AoA Lab Test Strategy IDD TDS Prelim Sys Spec Initial Transition Plan Tech Req Functionality Anl Operational Prototype Validation Final Transition Plan TDS/Acq Strategy Roadmap Final Sys Spec Manufacturing Plan Initial “Illities” Plan Design Codes Exit Criteria Relevant Env Test Design Risk Mit Brassboard Relevant Environment Test results Interface Doc Sys Config Formally Documented “illities” Documented TPMM Recommended Documentation Decomposition & Design Buede, The Engineering Design of Systems, 2000 Breadboard Laboratory Test results TPMM and the Systems Engineering “V” in TRL 4-6

16 “Secure the High Ground” TPMM High-Level Process Acquisition Customer

17 “Secure the High Ground” DAU adopted TTA Multi-Dimensional criteria set provides a comprehensive TRL Assessment Programmatics System Engineering Transition Management Systematic Development Methodology = Repeatable Process TDS establishes common language and vision ARCHITECTURAL VIEW FUNCTIONAL VIEW Acquisition Customer Program reviews include a TRA and a TAA

18 “Secure the High Ground” Physical View - Activity Centric Database Database: SQL Server App Environ: Windows Desktop Codebase:.NET Framework Dev Environ: Visual Studio 2005 Resources:

19 “Secure the High Ground” “TPMM: A Model for Technology Development and Transition” A TRL-based, Systems Engineering Activity Model that Assists: Technology Program Definition oIdentify Activities that will be performed oIdentify Documents that will be produced oProvide an Environment for Tailoring the Model oDevelop and Employ “Best Practice” Tools Technology Transition Management oTechnology Transition oTechnology Transfer oTechnology Marketing Technology Maturity Assessments oEstablishes Entry/Exit Criteria - Tailored for each Project oProvides a Framework for Performing Technology Readiness Assessments (TRA) Standardizes Tech Development, Assessment, & Transition

20 “Secure the High Ground” TPMM as an Enterprise Level Solution Mgt Functions Mgt Level Technology Program Definition Technology Maturity Assessment Technology Transition Management Tech Manager (Practitioner) ID activities performed by TRL ID documents that will be produced /delivered Develop and employ “Best Practice” Tools Establishes Technology Readiness Assessment Criteria Tailored to each program ID Technology Mgt Risks Early Customer/USER Involvement TTA’s  Interest  Intent  Commitment  Integration Opportunities Tech Transfer Opportunities Align DoD 5000 (Common Language) Transition Focus – Doing The Right Things At The Right Time With The Right People Portfolio Manager (Director) Portfolio Tracking Data Standardized Measurements Aligns technologies for cross pollination ID Program Mgt Risks Supports Key Decision Points Executive Manager Provides Enterprise Level Program Management Data Enterprise Assessment TRLs (Push / Pull) Funding Transition Support s Key Decision Points

21 “Secure the High Ground” Summary TPMM is an activity model for technology development that is partitioned into phases and gate-qualified using TRL’s. TPMM is a best practice standard that expands TRL understanding include detailed activities, exit criteria, and deliverables. TPMM is a toolset used by the Tech Manager to plan, guide and measure a technology program’s development maturity. TPMM is an alignment mechanism that promotes early focus on transitioning the technology to Acquisition Program Customers. TPMM acts as a common yardstick and provides the criteria to evaluating the Technology Development Strategy earlier. TPMM model provides a standard TRL criteria set for performing effective Technology Readiness Assessments at MS B

22 “Secure the High Ground” Request a copy of TPMM Version 2.pdf file at: Contact/Consultation Information Mr. Jeff Craver U.S. Army Space & Missile Defense Command Huntsville, Ala Voice: Cell: or Mr. Michael Ellis Dynetics, Inc. P.O. Box 5500 Huntsville, AL Voice:

23 “Secure the High Ground” BACKUP

24 “Secure the High Ground” TRL Rating Based on TPMM TPMM Phase Required Criteria Met/Not-Met Gap Analysis (on Un-Met) Risk Assessment on Gaps Technology Development Strategy TPMM Requirement? (TRL3 or beyond) Status = Draft, Preliminary, Final Updated for Current Phase? Gap Analysis/Percentage Populated Transition Management Customer/User/Sponsor ID’d TTA Version (Interest, Intent, Commitment) TTA Matrix Populated Signature Status TRL Roadmap TRL Milestone Schedule to transition TPR Status TPMM Quad Chart (Notional Tech Program Metrics) TPMM Quad Chart (Notional Tech Program Metrics) Current TRL confidence and Statement of Risk Programmatic Progress Transition Planning ProgressProgram Vision to Transition

25 “Secure the High Ground” Metrics-driven Executive Dashboard forms the basis of a Decision Support System (DSS) Facilitate Strategic Planning Technologies Distribution Technologies Gap Analysis Domain Analysis Skill gaps / recruiting needs (Develop/Maintain TC skill set) Diversified Portfolio Analysis Sponsor Science Discipline TTA Migration Status Status of Programs Transition Agreements in place Successful Transitions over time Program Distribution by TRL Technology Domain Science Discipline Sponsor Acquisition Customer Funding Executive Dashboard Captures the Enterprise View of Technologies in S&T

26 “Secure the High Ground” OrganizationDAU DOE LabsDTRANASAAEDCSMDTC S&T Organization Structure N/A Ad hocTransition Dir (TRIAD) ATDC Advanced Technology Development Center Tech Branch Technology Director Program Initiation Technology Development Strategy (TDS) Ad hoc Risk Reduction RequestFor Fee - Ad hoc Program Funding Program Portfolio Specific Budget Venture Funding Sponsor / Technologies Driver Needs Analysis ICD SE JSTO initiated NASA ReqInformalFeasibility Study [TPMM] Transition Management Technology Transition Agreements (TTA) Technology Transition Handbook TTAs -1 TTAs -3 [TPMM] Process Enablers TATMTRLsTRLs (+)TRLs TRL (+) [TPMM] Identified S&T Technology Management Best Practices Taken From Study Results performed for Department of Homeland Security S&T Directorate Oct/05