Presentation is loading. Please wait.

Presentation is loading. Please wait.

Joint Attack Munition Systems Project Office

Similar presentations

Presentation on theme: "Joint Attack Munition Systems Project Office"— Presentation transcript:

1 Joint Attack Munition Systems Project Office
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 Organization and Staffing Processes Practices
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 JAMS Family of Products
Laser HELLFIRE Longbow HELLFIRE 15+ Hellfire Variants Blast Frag Sleeve Joint Air-to-Ground Missile 2.75-inch Hydra Rocket System Missiles Rockets M272 Launcher M299A1 Launcher Small Guided Munitions M279 Launcher M310 Launcher Viper Strike UAS Launchers (repackaged M299 w/ 2 rails) 12 Tube Pod Launcher Test Station AN/AVM-101A TSGMS M260/M261 Rocket Launchers AN/TSM-205 Test Set Launchers Support Equipment HUTS

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

9 JAMS Organization Chart
PROJECT MANAGER DEPUTY PROJECT MANAGER Business Management Directorate Performance Management Directorate Logistics 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 Systems Engineering Management Technical Baseline Management
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 processes that 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 Processes Technical Baseline Management
Includes Requirements management Requirements documentation (e.g., specifications) Configuration management Change control Interface management (e.g., ICDs, ICWG) Reviews and audits

19 Processes Technical 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 Processes Technical 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 Processes Risk 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 Process must not lose sight of outcomes
Processes Summary 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 facilitate their 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 Processes Practices
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” of sound 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 – 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 – 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 – manufacturing processes under control for full-rate production decision) (See

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” of sound technical management

34 DoD SE Resources OSD Software and Systems Engineering website ( 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 (

35 Joint Attack Munition Systems Project Office
Contact Info Greg Wildman Joint Attack Munition Systems Project Office (256)

Download ppt "Joint Attack Munition Systems Project Office"

Similar presentations

Ads by Google