9. Implementation1 Implementation of Product-Based Approach r1. Optimization of product development r2. Allocation of familiar tasks

9. Implementation 1

Implementation of Product-Based Approach

1. Optimization of product development 2. Allocation of familiar tasks

9. Implementation 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

9. Implementation 3

Adapting the Process

Adapt process by Using PBD activities as template Adapting PBD activities to the program


9. Implementation 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


9. Implementation 5

Performing an Activity Once in an Enterprise

Work the following only once at the enterprise level

People Facilities Capital Tools


9. Implementation 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


9. Implementation 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


9. Implementation 8

Rolling Up Information

Maintain the following at the product level but roll results to top

Schedule Budget TPPs


9. Implementation 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


9. Implementation 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



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



Allowing people to focus on one area at a time improves productivity

People resist frequent changes of focus

Avoiding Change of Focus



Example 1 -- Writing

Focuses -- Content, grammar, and spelling Desirable -- Check each once per document Undesirable -- Check each once per sentence



Example 2 -- Requirements Management

Focuses -- Content, VM, and tracing Desirable -- Check each once per document Undesirable -- Check each once per requirement



Example 3 -- Documentation of Studies

Focuses -- Content and documentation Desirable -- Check each once per study Undesirable -- Check each once per update



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



Avoiding Low-Value Concepts

Error paths in processes Iteration in processes Studies without objectives

Editorial



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



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



Simpler Approach

Just do the task and not document ways of failing to reach the goal



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



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



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



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



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.



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


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



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




Reviews Technical audit plan

Risks Risk management plan

Technical performance measurements (TPPs) TPPs

Issues, problems, and actions Problem notification system Action item system




Configurations and changes Configuration management plan Spec control plan Documentation plan Drafting plan Data management plan

People Staffing plan




Facilities, tools, and capital Space and facilities plan Capital plan Security plan

Communications and library CALS implementation plan

Legal Contracts plan



Allocation to Understand Customer

Requirements spec Traceability plan



Allocation to Design (1 of 3)

Design guide Requirements spec Traceability plan Technology plan Spec tree




Integrated diagnostics plan EMC plan Maintainability program plan Reliability program plan System safety program plan Human engineering program plan




Logistics support analysis plan Integrated support plan Testability program plan Hazardous material management plan Training plan DTC/LCC plan



Allocation to Acquire Products

Material team Subcontracts management team



Allocation to Build

Test equipment and factory test plan Parts control Software quality program plan Hardware quality engineering plan Producibilty plan



Allocation to Verify

Test plan Test and evaluation master plan Test engineering automation plan



Allocation to Sell-Off

Warranty plan



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)



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


Documents

9. Implementation1 Implementation of Product-Based Approach r1. Optimization of product development r2. Allocation of familiar tasks