1 Agenda for implementation of PBDA r1. Optimization of product development r2. Heuristics r3. Application notes r4. Questions to identify risks

2 1. Optimization of product development rAdapting the process rPerforming an activity once rOmitting activities rUsing one group of people rRolling up information rEmbedding tasks rDoing what people do naturally rAvoiding duplication rAvoiding low-value concepts rAvoiding events that are OBE rAvoiding over-run 1. Optimization of product development

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

4 Performing an activity once (1 of 2) rPerform 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 (2 of 2) rWork the following only once at the enterprise level People Facilities Capital Tools 1. Optimization of product development

6 Omitting activities rExamples of products not needing the acquire activity Software Providing a service Products having no lower products rExample of product not needing activities after design Studies rExample 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) rUsing 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 rMaintain the following at the product level but roll results to top Schedule Budget TPPs 1. Optimization of product development

9 Embedding tasks rEmbed 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 (1 of 6) rProductivity can be increased by asking people to do things they do naturally rPeople resist doing work the hard way rExamples Using familiar tools Avoiding change of focus Avoiding unuseful work 1. Optimization of product development

11 Doing what people do naturally (2 of 6) rUsing 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 Doing what people do naturally (3 of 6) rAvoiding 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 Doing what people do naturally (4 of 6) rExample 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 Doing what people do naturally (5 of 6) rExample 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 Doing what people do naturally (6 of 6) rExample 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 rAvoid 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 (1 of 4) rAvoiding error paths in processes rAvoiding iteration in processes rAvoiding studies without objectives Editorial 1. Optimization of product development

18 Avoiding low-value concepts (2 of 4) rAvoiding error paths in processes Assume a success; 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 Just do the task and not document ways of failing to reach the goal 1. Optimization of product development

19 Avoiding low-value concepts (3 of 4) rAvoiding 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 Avoiding low-value concepts (4 of 4) rAvoiding 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

21 Avoiding events that are OBE (1 of 2) rCost can be saved by not dwelling on work that has been overcome by events (OBE) rThere 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

22 Avoiding events that are OBE (2 of 2) rObjects that are in one of these two main sets are easier to maintain rObjects not in one of these two sets are ignored and become obsolete rExamples are Plans Studies Justifications Traces 1. Optimization of product development

23 Avoiding over-run (1 of 2) rProductivity can be improved by ensuring that the product engineering staff doesn’t get over-run by development of lower products rLower products depend upon receiving requirements from a higher product 1. Optimization of product development

24 Avoiding over-run (2 of 2) rIf 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. rA priority of product engineering is to provide product design that results in specifying the requirements for the lower product. 1. Optimization of product development

25 2. Heuristics rDefinitions rExamples 2. Heuristics

26 Definition rHeuristic definition Rules of thumb rRule of thumb definition A rule based on practical experience without reference to scientific principals May have widespread validity, but may not always be true 2. Heuristics

27 Examples (1 of 3) rExample 1 -- People Good people are number one priority Better to have good people and bad process than good process and bad people rExample 2 -- Planning Plan the work and work the plan Develop requirements as if they were going to be implemented by another company Don’t confuse requirements and design 2. Heuristics

28 Examples (2 of 3) rExample 3 -- Hierarchy Don’t confuse requirements and levels of hierarchy RAA for a product should rest with only one IPT rExample 4 -- Order of tasks Parallel is good; serial is bad rExample 5 -- Partitioning Maximize cohesion and minimize coupling 2. Heuristics

29 Heuristics (3 of 3) rExample 6 -- Control Push control to the lowest level rExample 7 -- Optimization Work first; optimize last Simplify 2. Heuristics

30 3. Application notes rSimple products rIncremental builds rSpiral development rPrototypes rEnterprise boundary rLess-than-optimum design rLess-than-optimum team rCommon component rAlgorithms rReduction of hierarchy rState of mind 3. Application notes

31 Simple Products rSome developments don’t require all seven activities Study Concept Purchased product Service 3. Application notes

32 Incremental builds rIncremental builds allow parallel design and build build 1 build 2 build 3 single product multiple products 3. Application notes

33 Spiral development (1 of 2) functionform build certify final form intermediate form 2 intermediate form 1

34 Spiral development (2 of 2) rAnother form of Incremental builds that allow parallel design and build 3. Application notes

35 Prototypes rPrototypes are a separate set of PBDs rDocumentation may be less rigorous product prototype 3. Application notes

36 Enterprise boundary cattle locating device cattle cameracattle imager and display camera image processing hardware display computer display software company 1 company 3company 2 Splitting a product on an enterprise boundary may be a problem

37 Less-than-optimum design (1 of 2) cattle locating device cattle imagercattle display camera image processing hardware display display computer display software system IPT Subsystem 6 IPT 3. Application notes Overcome by negotiation or mapping

38 Less-than-optimum team (2 of 2) cattle locating device cattle cameracattle imager and display camera image processing hardware display display computer display software system IPT subsystem 6 IPT subsystem 5 IPT Overcome by negotiation or mapping

39 Common component rCommon components can be treated as shared products system unit common CSCI 3. Application notes

40 Algorithms rAlgorithms can be treated as another product system algorithmsunit CSCI 3. Application notes

41 Reduction of hierarchy cattle locating device camera image processing hardware control computer control software display display computer display software find and display cattle make image extract cattle locations control hardware display cattle control display rReducing hierarchy reduces number of products 3. Application notes

42 State of mind rThe application of the PBDA approach is a state of mind. rIt’s the ability to reduce clutter by treating a product as a set of products and then being able to apply the PBDA activities to each product. 3. Application notes

43 4. Questions to identify risks rPeople rFeasibility risks rCompany and management support rControl rDecision making rManufacturing risk rUnderstanding customers rCustomer and contractor together rCommunications rDefinition of complete 4. Questions to identify risks

44 People rQuestion:: How is the program staffed? rDesirable answer People who take ownership People skilled in relevant technology and management People who can work in teams People who aren’t parochial People who have big-picture perspective Method for moving people on, off, and around the program 4. Questions to identify risks

45 Feasibility risks rQuestion : How close to limits are science and engineering; e.g. state-of-the-art performance, throughput, memory, weight, power, cooling, testability, reconfigurability, and manufacturability? rDesirable answer We’ve done this before We’re not pushing laws of physics We’re not pushing limits Risk is managed 4. Questions to identify risks

46 Company and management support rQuestion: Do the company and management support the program? rDesirable answer People and resources are available There are company visibility and people rewards 4. Questions to identify risks

47 Control rQuestion: How is the program controlled to be successful? rDesirable answer Limited number of effective metrics that include cost, schedule, risk, and performance Frequent error detection and correction Deviations corrected as opposed to only observed Future work anticipated and provided for 4. Questions to identify risks

48 Decision making rQuestion: How does the program make and enforce decisions? rDesirable answer Means for understanding options Means for getting consensus Means for propagating and enforcing decisions 4. Questions to identify risks

49 Manufacturing risk rQuestion: Are all the components proven and readily available off-the shelf? rDesirable answer Everything is COTS We’re not developing hardware or software We’re not having someone else develop hardware and software 4. Questions to identify risks

50 Understanding customers rQuestion: Who are the customers and users, and what do they expect? rDesirable answer Customers and users identified Expectations understood and agreed to with the customers 4. Questions to identify risks

51 Customer & contractor together rQuestion Do customer and contractor work together for program success? rDesirable answer Customer and contractor on same team, and both feel ownership for project success Contractor and customer work together as opposed to being in conflict Customer and contractor support streamlining, and work to move program forward Customer and contractor solve problems together 4. Questions to identify risks

52 Communications rQuestion: How do all phases of the program work in parallel? rDesirable answer Organizations that reflect the hierarchy , intranet, libraries, and electronic documents Environment and tools to do the job Teams that communicate and that have clear responsibilities Know customer, product, and team interfaces 4. Questions to identify risks

53 Definition of complete rQuestion: How do people and the program know when they’re done? rDesirable answer Defined tasks with measurable completion criteria 4. Questions to identify risks