Implementation of Product-Based Approach

1. Implementation of Product-Based Approach • 1. Optimization of product development • 2. Allocation of familiar tasks

2. 1. Optimization of Product Development • Adapting the process • Performing an activity once • Omitting activities • Using one group of people • Rolling up information • Embedding tasks • Doing what people do naturally • Avoiding duplication • Avoiding low-value concepts • Avoiding events that are OBE • Avoiding over-run 1. Optimization of product development

3. Adapting the Process • Adapt process by • Using PBD activities as template • Adapting PBD activities to the program 1. Optimization of product development

4. Performing an Activity Once in a Program • Perform the following tasks once at the program level • Processes • Tools • Communications and library • Life cycle plan • IMP, SEMP, SDP 1. Optimization of product development

5. Performing an Activity Once in an Enterprise • Work the following only once at the enterprise level • People • Facilities • Capital • Tools 1. Optimization of product development

6. Omitting Activities • Examples of products not needing the acquire activity • Software • Providing a service • Products having no lower products • Example of product not needing activities after design • Studies • Example of products not needing verify activity • Program that move all testing to the highest level 1. Optimization of product development

7. Using One Group of People (1 of 2) • Using a common group of people for each of the following across all products • Reliability • Maintainability • Safety • Supportability • Training • Test planning 1. Optimization of product development

8. Rolling Up Information • Maintain the following at the product level but roll results to top • Schedule • Budget • TPPs 1. Optimization of product development

9. Embedding Tasks • Embed the following as indicated • Processes into PBD activities • Plans into the schedule • Trade studies and analysis into requirements, design, and verification • Validation into requirements and design • Testability, supportability, reliability, and maintainability into design 1. Optimization of product development

10. Doing What People Do Naturally • Productivity can be increased by asking people to do things they do naturally • People resist doing work the hard way • Examples • Using familiar tools • Avoiding change of focus • Avoiding unuseful work 1. Optimization of product development

11. Using Familiar Tools • Allowing people to use familiar tools improves productivity • People prefer using tools they’re use to • For example, people prefer using Word, Excel, and PowerPoint rather than data base tools like RTM, SLATE, or DOORS 1. Optimization of product development

12. Avoiding Change of Focus • Allowing people to focus on one area at a time improves productivity • People resist frequent changes of focus 1. Optimization of product development

13. Example 1 -- Writing • Focuses -- Content, grammar, and spelling • Desirable -- Check each once per document • Undesirable -- Check each once per sentence 1. Optimization of product development

14. Example 2 -- Requirements Management • Focuses -- Content, VM, and tracing • Desirable -- Check each once per document • Undesirable -- Check each once per requirement 1. Optimization of product development

15. Example 3 -- Documentation of Studies • Focuses -- Content and documentation • Desirable -- Check each once per study • Undesirable -- Check each once per update 1. Optimization of product development

16. Avoiding Duplication • Avoid duplication in the following areas • Requirements between levels in the product hierarchy • Requirements between requirements, design, and verification descriptions • Tutorial information such as product descriptions • Designs between levels of product hierarchy • Analyses and trade studies resulting from having lost earlier versions 1. Optimization of product development

17. Avoiding Low-Value Concepts • Error paths in processes • Iteration in processes • Studies without objectives Editorial 1. Optimization of product development

18. Avoiding Error Paths in Processes • Assume a success-oriented attitude; and if an obstacle presents itself, find a way around the obstacle. • Error paths in processes appear to give completion since they represent the path to be taken in case of an undesired outcome • Error paths clutter process diagrams, require time to obtain agreement on their design and are almost never tracked in processes 1. Optimization of product development

19. Avoiding Iteration in Processes • Avoid iteration in processes • Iteration and recursion in process diagrams reflect a common practice • The common practice is to try to do something; and then if unsuccessful, try again. • Like error paths, iteration and recursion require time to obtain agreement on their design and are almost never tracked in processes 1. Optimization of product development

20. Simpler Approach • Just do the task and not document ways of failing to reach the goal 1. Optimization of product development

21. Avoiding Studies without Objectives • Give objectives to trade studies and analysis • Treat as tools and use them when needed • Avoid performing them for their own sake 1. Optimization of product development

22. Avoiding Events that are OBE (1 of 2) • Cost can be saved by not dwelling on work that has been overcome by events (OBE) • There are two main sets of management objects in developing a product • 1. Management objects • 2. Objects involving design, lower product requirements and interfaces, test specs, and test procedures 1. Optimization of product development

23. Avoiding Events that are OBE (2 of 2) • Objects that are in one of these two main sets are easier to maintain • Objects not in one of these two sets are ignored and become obsolete • Examples are • Plans • Studies • Justifications • Traces 1. Optimization of product development

24. Avoiding Over-Run (1 of 2) • Productivity can be improved by ensuring that the product engineering staff doesn’t get over-run by development of lower products • Lower products depend upon receiving requirements from a higher product 1. Optimization of product development

25. Avoiding Over-Run (2 of 2) • If the higher product don’t provide the requirements needed by the lower product, then the lower products will pass the higher product and ignore its direction. • A priority of product engineering is to provide product design that results in specifying the requirements for the lower product. 1. Optimization of product development

26. 2. Allocation of Familiar Tasks • There are a large number of tasks that appear in literature relating to developing products • The allocation given in the following vugraphs show where these tasks can fit into the product-based development approach 2. Allocation of familiar tasks

27. Objective of Allocation • Reduce the number of separate tasks into the maintenance of the much smaller set of management objects used in the PBD approach 2. Allocation of familiar tasks

28. Allocation to Manage (1 of 4) • Life cycle plan • Life cycle plan • Schedule and budget • Budget • Schedule • WBS • C/SCS plan • Financial control plan • Contracts plan 2. Allocation of familiar tasks

29. Allocation to Manage (2 of 4) • Reviews • Technical audit plan • Risks • Risk management plan • Technical performance measurements (TPPs) • TPPs • Issues, problems, and actions • Problem notification system • Action item system 2. Allocation of familiar tasks

30. Allocation to Manage (3 of 4) • Configurations and changes • Configuration management plan • Spec control plan • Documentation plan • Drafting plan • Data management plan • People • Staffing plan 2. Allocation of familiar tasks

31. Allocation to Manage (4 of 4) • Facilities, tools, and capital • Space and facilities plan • Capital plan • Security plan • Communications and library • CALS implementation plan • Legal • Contracts plan 2. Allocation of familiar tasks

32. Allocation to Understand Customer • Requirements spec • Traceability plan 2. Allocation of familiar tasks

33. Allocation to Design (1 of 3) • Design guide • Requirements spec • Traceability plan • Technology plan • Spec tree 2. Allocation of familiar tasks

34. Allocation to Design (2 of 3) • Integrated diagnostics plan • EMC plan • Maintainability program plan • Reliability program plan • System safety program plan • Human engineering program plan 2. Allocation of familiar tasks

35. Allocation to Design (3 of 3) • Logistics support analysis plan • Integrated support plan • Testability program plan • Hazardous material management plan • Training plan • DTC/LCC plan 2. Allocation of familiar tasks

36. Allocation to Acquire Products • Material team • Subcontracts management team 2. Allocation of familiar tasks

37. Allocation to Build • Test equipment and factory test plan • Parts control • Software quality program plan • Hardware quality engineering plan • Producibilty plan 2. Allocation of familiar tasks

38. Allocation to Verify • Test plan • Test and evaluation master plan • Test engineering automation plan 2. Allocation of familiar tasks

39. Allocation to Sell-Off • Warranty plan 2. Allocation of familiar tasks

40. Allocation Vs Management Plans • The preceding allocations didn’t show accumulation plans • Examples are • Integrated management plan (IMP) • System engineering management plan (SEMP) • Software development plan (SDP) • Hardware management plan (HDP) 2. Allocation of familiar tasks

41. Conclusion of Allocation • Maintaining a few documents focused into a few areas is easier than maintaining a large number of documents that are not related 2. Allocation of familiar tasks