Missile Systems Engineering: Is It Rocket Science? Systems Engineering Best Practices

1. Missile Systems Engineering:Is It Rocket Science?Systems Engineering Best Practices March 3, 2009 Greg Wildman Joint Attack Munition Systems Project Office DISTRIBUTION A: Approved for public release; distribution is unlimited.

2. What Is a Best Practice? A best practice is Any practice, knowledge, know-how, or experience that has proven to be valuable or effective within one organization that may have applicability to other organizations. • Levels of best practices • Good idea • Good practice • Local best practice • Industry best practice Attributed to Chevron Corporation in If Only We Knew What We Know, O’Dell et al (1998)

3. Purpose Present systems engineering practice, experience, and ideas from the Joint Attack Munition Systems (JAMS) Project Office To … Inform and inspire you to apply these principles to further the practice of systems engineering in your organization and facilitate program success

4. Topics • Organization and Staffing • Processes • Practices

5. Organization In a balanced organization, working towards a common objective, there is success. Sir Arthur Helps The trouble with organizing a thing is that pretty soon folks get to paying more attention to the organization than to what they're organized for. Laura Ingalls Wilder

6. Joint Attack Munition Systems • Project office within the US Army Program Executive Office, Missiles and Space • Mission • World-class life-cycle management of the joint warfighters’ air-launched rocket, missile, launcher systems and Viper Strike

7. Blast Frag Sleeve Laser HELLFIRE Longbow HELLFIRE Joint Air-to-Ground Missile M299A1 Launcher M272 Launcher M310 Launcher 12 Tube Pod JAMS Family of Products 15+ Hellfire Variants 2.75-inch Hydra Rocket System Missiles Rockets Small Guided Munitions M279 Launcher Viper Strike UAS Launchers (repackaged M299 w/ 2 rails) Launcher Test Station AN/AVM-101A TSGMS AN/TSM-205 Test Set M260/M261 Rocket Launchers Support Equipment Launchers HUTS

8. JAMS Supported andFuture Platforms MH-60 Blackhawk OH-58D Kiowa Warrior AH-64A/C Apache AH-64D Apache Longbow AH-1 Cobra F/A-18 Hornet SH-60 Seahawk MQ-1B Armed Predator UAVER/MP Warrior UAV

9. JAMS Organization Chart PROJECT MANAGER DEPUTY PROJECT MANAGER Logistics Directorate Business Management Directorate Performance Management Directorate Systems Engineering Directorate Product Managers JAGM System JAGM System Security Office International Office HELLFIRE System HELLFIRE System Small Guided Munitions Structures & Ordnance Small Guided Munitions Platform Integration & Launchers Aviation Rockets Systems Engineering Management Software/ Simulation

10. Organization • Systems Engineering Directorate • Product system divisions (e.g., Hellfire or JAGM) • Headed by product Lead Systems Engineer (LSE) • Single technical focal point responsible for technical management and execution of performance, cost, and schedule • Supported by cross-functional IPTs, typically via a Systems Engineering Integration Team (SEIT) • Systems Engineering Management Division • Provides systems engineering (SE) support to the product LSE Hybrid product/functional SE organization provides coordinated technical management and SE of each product

11. SE Management Division • Mission • To ensure that the systems engineering (SE) approach is applied to the development, production, and operations/support phases of the JAMS project office family of products • Acts as the SE “conscience” for the product systems engineer • Serves as subject matter expert (SME) for SE processes SE Management provides support to LSE to ensure SE processes are not pushed to the back burner in the daily press of technical performance/cost/schedule management activities

12. Staffing The old adage “People are your most important asset” is wrong. People are not your most important asset. The right people are. Whether someone is the “right person” has more to do with character traits and innate capabilities than with specific knowledge, background, or skills. Good to Great, Collins (2001)

13. Systems Engineering Traits • Embrace SE as a way of thinking • Systems thinking • Critical thinking • Integrate across the organization • “Connect the dots” both horizontally and vertically • Focus on process • But not just for the sake of process • See the big picture • Yet be able to work the details • Be a team player • IPTs • Communication • Collaboration Not everyone is cut out to be an effective Systems Engineer!

14. Systems Engineering Skills • Experience • Breadth over depth • IPT/team/technical project lead roles • Can be a challenge to guide employees into candidate job experiences • Always be on the lookout for the right people • Training • Education – Bachelors/Masters/Doctorate • DAWIA certification – including SPRDE-PSE for LSEs • INCOSE Systems Engineering Professional Certification • Other systems engineering certificates (e.g., UAHuntsville) A variety of formal training and on-the-job opportunities are available to develop employees’ abilities in SE processes

15. Process Efficiency is doing things right; effectiveness is doing the right things. Peter Drucker If you can’t describe what you are doing as a process, you don’t know what you’re doing. W. Edwards Deming

16. SE Processes Systems Engineering Management Technical Reviews Technical Controls Technical Baseline Management Decomposition and Definition Integration and Verification Risk Management Technical Planning Implementation Systems Engineering Vee Systems Engineering Management comprises a set of processesthat are enablers for systems engineering success on programs

17. Processes Technical Planning • Technical plans such as • Systems Engineering Plan (SEP) – typically a government document • Systems Engineering Management Plan (SEMP) – typically a contractor document • Requirements Management Plan • Program plans such as • Risk Management Plan • Integrated Master Plan Plan the work and work the plan.If you fail to plan, you plan to fail.

18. ProcessesTechnical Baseline Management • Includes • Requirements management • Requirements documentation (e.g., specifications) • Configuration management • Change control • Interface management (e.g., ICDs, ICWG) • Reviews and audits

19. ProcessesTechnical Reviews • Reviews (e.g., PDR, CDR) conducted between the government and the contractor to assist in assessing: • Technical maturity of the design • Technical progress of the program • Readiness to proceed to the next phase of the program

20. ProcessesTechnical Controls • Technical measures to determine program progress, risk, and status. May be common with programmatic controls. Include: • Technical performance measures (TPMs) • Critical technical parameters (CTPs) • Software development metrics • Integrated master schedule (IMS) • Earned value data

21. ProcessesRisk Management • Integrated program management and systems engineering process to address future adverse outcomes • Includes: • Risk identification • Risk analysis • Risk mitigation planning • Risk mitigation plan implementation • Risk tracking • Assesses likelihood and consequence of technical performance, cost, and schedule risks

22. ProcessesSummary • SE Processes • Technical planning • Technical baseline management • Technical reviews • Technical controls • Risk management • Process must not lose sight of outcomes “High mileage” SE processes for the JAMS project office –SE Management organization “owns” these processes to facilitatetheir accomplishment for program success

23. Practices Knowing is not enough; we must apply. Willing is not enough; we must do. Goethe When it comes to getting things done, we need fewer architects and more bricklayers. Colleen C. Barrett, Southwest Airlines

24. Putting Process into Practice • Examples of how to implement these systems engineering processes on a program • Most of these practices are in use on JAMS programs

25. Practices Technical Planning • Planning must be specific to the program • Don’t just do it the same as the last program • Tailor planning to address the technical risks of the program, consistent with the acquisition strategy • Assign senior personnel to develop plans • Conduct SE WIPT with OSD to assist with SE planning • Write a SEP even if it’s not required (non-oversight program) • Contractor SEMP should integrate with and expand upon government SEP – documents a shared view of technical planning for the program • Include notional IMP in the request for proposal • Use IMP to aid in defining technical review entry criteria • Consider evaluation of offerors’ proposed SEMP, IMP, and risk management plan during source selection • Don’t write “shelfware” – ensure plans are being followed –if they’re not, maybe they need to be revised

26. Practices Technical Baseline Management • Implement typical configuration management practices (CCB, audits, etc.) • Use interface controls as applicable (e.g., ICDs, ICWG) • Require disciplined, structured requirements management process • Seriously consider use of a database tool (e.g., DOORS®, CORE®) • Include traceability of requirements, rationale for requirements allocation and flowdown • Trace from top-level customer requirements down to component requirements – include ICDs as well as specifications • Trace from requirements to verification of those requirements – link to test planning documentation • Link to trade studies, design analyses, and architectures Requirements are like children – left on their own, they may not mature into what you want them to be

27. Practices Technical Reviews • Use entry criteria to determine readiness for the review – event-driven vice schedule-driven • Include program-specific entry/exit criteria, not just generic guidance; document in SEP/SEMP and contract • Use DoD risk assessment checklists to assess the program's technical design maturity and technical and programmatic risks • Include independent assessors/review board members (DoD best practice is for independent chairperson) • Include logistics and manufacturing considerations in all reviews, applicable to the phase of development Use exit criteria as opportunities to assess technical maturity and progress/readiness to move to the next phase

28. Practices Technical Controls • The technical team needs to regularly monitor IMS, EVMS, TPMs, and risks • Integrate IMS, EVMS, TPMs, and risk • IMS and EVMS – standard association • IMS and risk – risk mitigation plans, schedule risk assessment • TPMs and risk – assess technical maturity • TPMs and EVMS – links technical accomplishment with earned value • Tie TPMs to key performance parameters (KPPs) Technical controls and metrics facilitate early identification of problems and inform appropriate course correction – but they must be used to be effective

29. Practices Risk Management • Don’t use the risk management process to address issues/problems • If the likelihood of occurrence is 100%, it’s an issue rather than a risk • Conduct a risk assessment to aid in determining acquisition strategy and contractual requirements • Convene a periodic joint government-contractor risk review board to identify and analyze risks and determine mitigation plans • Use quarterly schedule risk assessment to assist in identifying schedule risks • Use technical review risk assessment checklists to assist in identifying risks Unmanaged risks are likely to become problems

30. Summary • Organization • Conscious organizational design provides program technical leadership (lead systems engineer) and SE process expertise • Processes • SE management processes support classical SE and technical management functions • Practices • SE practices implement processes to meet specific program needs Systems Engineering is the “common sense” ofsound technical management

31. GAO Assessment of Best Practices • Mature technologies, stable design, and mature production processes demonstrated at key knowledge points • Development start (MS B): technologies, time, funding, and other resources match customer needs; critical technologies mature at MS B, demonstrated by PDR and prototypes (addressed in new DoDI 5000.02 – competitive prototyping and PDR prior to or just after MS B) • Design review (CDR): design performs as expected and is stable; 90% of engineering drawings complete and released by CDR (DoDI 5000.02 – post-CDR assessment to enter system capability and manufacturing process demonstration • Production start (MS C): production meets cost, schedule, and quality targets; all critical processes under statistical control (DoDI 5000.02 – manufacturing processes under control for full-rate production decision) (See http://www.dtic.mil/ndia/2008systems/7070masters.pdf)

32. What Is a Best Practice? • Good idea • Good practice • Local best practice • Industry best practice Hopefully you’ve been reminded of good practices and been given ideas that you can apply to your organization and your program Sharing and using good ideas and practices lead to eventual local and industry adoption as best practices

33. Is It Rocket Science? • Systems engineering success isn’t magic • It’s the disciplined application of people, processes, and practices to define, document, and verify the requirements of a system and to manage the technical aspects of the program over the life cycle Systems Engineering is the “common sense” ofsound technical management

34. DoD SE Resources • OSD Software and Systems Engineering website (http://www.acq.osd.mil/sse/) • Defense Acquisition Guidebook • Systems Engineering Preparation Guide • Systems Engineering Guide for Systems of Systems • Guide for Integrating Systems Engineering into DoD Acquisition Contracts • Risk Management Guide for DoD Acquisition • Integrated Master Plan / Integrated Master Schedule Preparation and Use Guide • Technical Review Checklists (https://acc.dau.mil/CommunityBrowser.aspx?id=144143)

35. Contact Info Greg Wildman Joint Attack Munition Systems Project Office greg.wildman@msl.army.mil (256) 842-7028