N. RADC-TR- 65-475

CRITERIA FOR VALUE ENGINEERING

PHASE I

FEASIBILITY STUDY

R. E. PurvisR. L. McLaughlin

RCA Service Company

TECHNICAL REPORT NO. RADC-TR- 65-475February 1966

CLEARI NG'OUS EFOR FEDERAL SCIENTIFIC AND

TECHNICAL INFF.C-) ,AT ION1ardcopy j •i•rofie12 1e

Distribution of this documenit is unlimited

A

Reliability Branch

Rome A.r Development CenterResearch and Technology D'viion

Air Force Systems CommandGriffiss Air For-e Base, New Yor'" T

CRITERIA FOR VALUE ENGINEERING

PHASE I

FEASIBILITY STUDY

R. E. PurvisR. L. McLaughlin

RCA Service Company

Distribution of this document is unlimited

,T-1,C, GV1-, N.Y., 23) mat 66-80

FOREWORD

This report was prepared by Messrs. R.E. Purvis and R.L. McLaughlin,Radio Corporation of America, RCA Service Company Divisi.on, Alexandria,Virginia 22314, under Contract AF30(602)-3850, Project 5519, Task 551901.Mr. Julius Widrewitz (EMERE) was the RADC Project Engineer.

This technical report has been reviewed and is approved.

Approved •- ,J'IJUS WIDREWIT±'Systems Effectiveness OfficeReliability Branch

Approved: t .

D ýRER- Chlh ef, Reliability Branch

Engineering Division

ii

I

This report summarizes the state-of-the-artof Value Engineering. A proposed structurefor a general value analysis technique alongwith quantification of value is presented.Based on the proposed structure a generalmethod for resource cost optimization isdeveloped.

'Iii

TABLE OF CONTENTS

Page

1. INTRODUCTION . . . . . . . . . . . . . . . .1

2o STATE-OF-THE-ART . . ....... . . . . . . . I

2.1 Present Status e. . ... . . .a. . . . 12.2 Present Problems ...... e a • e • . . 3

3. THE DECISION ENVIRONMENT . . . . .. . . . . . 3

3.1 General . . . . . . . . . . . . . . . a . 3

3.2 Value Engineering Fundamentals . . . . . 53°3 Phases of Design and Operation . . . . . . 11

4. PROPOSED STRUCTURE ............. . . 15

4.1 General . 154.2 Definition of Objective....... . . . . 164°3 Cost Analysis . .. . . .. .o 0 o 0 a . 20

4.4 Detailed Cost Procedure ao o . o . o & . 24

5. SUMMARY .e . .. . . . .e e e . e . . . .* 31

6. PLAN FOR PHASE II ,. .* *. e e . a . * 32

6.1 General . . . . . . * * 0 0 0 0 32

6.2 Structure . . . . . . . .ego.... o .* 32

6.3 Validation . . . .... . ..... . 32

6.4 Implementation . . . . ..... . . . 35

BIBLIOGRAPHY .g. . . .... . ... . . . . . . . . . 36

APPFNDIX - Literature Search .. . . .. . o .. 38

i •u •V

4

N LIST OF ILLUSTRATIONS

Figure Page

3-1 System Disciplines . . . . . . . . . . . . 43-2 System Development . . . . . . ...... 123-3 System Program Phasing . . . . o . . . . . 144-1 Cost Changes . . . . . . . . . . .. . 184-2 The Decision Tree. ..... . .. . . . 224-3 Cost Model . . . . . . . . . . . . * . . 254-4 Cost Decision Elements . . . . . . . . . . 306-1 Development Schedule . . . . . . . . . . . 33

Table Page

3-1 Parameter Definition . ...... . . . . 9

VI

-a-.

1. INTRODUCTION

This report is the result of effort performed under Phase Iof AP30(602)-3850. The purpose of this report is asfollows:

a. To summarize the findings of a value analysisliterature review.

b. To develop the logic of a value analysis methodol-ogy applicable to the conceptual and definitionphases of system development.

c. To develop a schedule for the proposed Phase IIprogram.

2. STATE-OF-THE-ART

2.1 Present Status

The evaluation of function is the present state-of-the-artof value engineering theory. And the basic tool may besummarized as a series of questions directed to functionevaluation:

a. What is the product?

b. What is the function of the product?

c. How well does the product perform the function?

d. Are there acceptable alternatives for the designof the product for cost reduction and comparablequality?

This value engineering approach represents a qualitativerather than a quantitative process.

This tool applied to military value analysis takes thefollowing additional forms:

a. Question constraints of contract. Does thecontract cover or exceed the requirement ofthe function of the product? There are twotypes of requirements generally invoked incontracts: system operational requirement Jand military specification standards. Systemoperational requirements constitute the bigpicture and are generally peculiar to thesystem. These requirements are mission/environment oriented. Military specificationstandards are detail part/performance require-ments.

b. Question miasion of the product.Will the product perform the mission called forin the contract and specifications?

c. Question constraints of the "abilities," e.g.,reliability.Are the constraints of the other "abilities" com-patible with the requirements of value for costreduction?

d. Question alternatives to the design.What alternative designs are possible to performthe required function of the product within theparameters of specifications, cost, and value?

e. Question the parameters of the function of theproduct.Will the product perform the required function withthe present design?

The existing value methodology is primarily used as anafter the fact cost reduction mechanism. As a matterof fact, considerable value analysis effort is performedin the proposal, definition, and design phases of systemdevelopment; but it is given scant recognition as such,due simply to the mensuration problems associated withcost savings.

There is in value literature a wealth of idea or genera-tion of alternative devices both of a general nature andeven categorized by problem type; e.g., to buy or make.

2

1 I

2.2 Present Problems

The existing problems of the value engineering d&3ciplineare as follows:

a. Need for quantitative criterion for value pointingup difference between value and cost.

b. Need to orient value analysis to total expectedresource cost.

c. Need for a feasible systematic procedure forevaluation of feasible alternatives.

d. Need to reorient value analysis to the objectiveof elLmination of excessive cost rather than reduc-tion in cost, e.g., do it right the first time.How much can be saved by decreasing the value ofthe system (decreasing performance goals, eg.,reliability)?

e. Need to project alternatives into total costpicture early in the conceptual phases of systemdevelopment; thus a means of making the systemscircuit, and packaging engineer aware of total costimplications.

3. THE DECISION ENVIRONMENT

3.1 General

This section is directed to establishment of the fundamen-tal concepts, working definitions for the value methodology,and the program time frame in which value analysis must bcperfored. For the purpose of this study, value engineer-ing is considered to be that discipline directed to analysisof how system and %quipment are related, whereas, systemengineering is directad to analysis of the relationbetween mission ard the system. Thus as the systemseffectiveness a:n',t is related to the system engineerso is the value analyst related to the design engineer.Pictorially this relationship is shown in figure 3-1.

NN

U,t

z>1 IHHl

aol 0%

'-4

tp 4

F-4-

tonto)

.IJU

The elements in common between system effectiveness andsystem value are the hardware/software to implement thesystem and the cost aspects of the hardware/softwarewith related support aspects. Additionally, the inter-face of systems effectiveness and system value revolvesabout the method of implementing the function. Ingeneral, this will- be hardware, but may be processes,schedules, etc., - anything involving program schedule,total expected cost, or performance.

3.2 Value Engineering Fundamentals

3.2.1 'General - A general value engineering methodologymust meet certain specific requirements; these require-ments are as follows:

a. The desired method should be useful forobjectively quantifying value:

1. As a tool for design decision through allproject phases.

2. In the development of proposals.

3. In the evaluation of proposals.

4. For monitoring the value level of systems/equipment undergoing development.

b. The method should have application to the bulkof military systems, equipments, missions, andsituations.

c. The method must be technically valid and usefulin practice as follows:

1. It must provide realistic guidance for trade-offs between functional levels of performanceand the costs of ownership and operation.

5

2. It should take into account the skill level ofthe average user (both contractor and customer)and the conditions under which it will be used.

3. The data required, and the actions to betaken to reach meaningful decisionst must besequenced and timed to match normal programphasing.

4. The method should be capable of adjustment tomaintain its validity in the face of advancesin design, systems support policies, andmission requirements, as well as advances inanalytical tools and the quality of availabledata.

5. The degree of refinement of a model ortechnique should be compatible with thebasic accuracy and variability of thedata needed for its use and the sensitivityof the output to variations in input.

6. The time and cost required to carry out theprocedure at any phase of the development cycleshould be compatible with design schedules andbudgets. The cost of carrying out the pro-cedure must not be disproportionate to thegains expected from its use.

In the past a number of factors have militated againstmeeting these requirements and care must be exercised indeveloping the approach without succumbing to the samepitfalls.

One pitfall is the faildre to recognize that values have anexistence at least semi-independenit of cost. For instance,a battleship cut up for scrap has far less value than whenit proudly joined the fleet. Yet many more dollars havegone into the operational and scrapping costs. A techno-logical breakthrough can drastically reduce the cost of anequipment without affecting the value of the equipment atall.

6

A second pitfall is the not infrequent belief that allvalue parameters can be optimized at once. In most realcases (given a sound design to start with) it is notfeasible to improve one function, indiscriminately, with-out adversely affecting others.

A third pitfall is a widely held tendency to look forabsolute invariant value independent of the particularapplication and the paiticular user. A glass of waterto a man on the desert has a value quite different fromthat it has for a man drowning in a lake. Obviously,elements of value are desire or need, and difficulty ofacquisition.

The elements of value have, in present literature, beencombined to arrive at a total figure of merit. Thisassumes discrete, mutually exclusive, parameters orcourses of action; since this is not always the case,it is necessary to use more rigo::ous methods of combina-tion, or to determine what errors are introduced byassuming that several parameters are independent, evenif, in fact, they are not.

it is desirable not only to develop criteria formeasuring value, but also to develop criteria forselection of areas of high yield. This will involveelements of timeliness and feasibility as well as suchelements of yield as annual or contract cost of producing,the cost of operation and maintenance, complexity, ratioof special parts to standard parts, state-of-the-art,design maturity, and remaining useful life.

3.2.2 Definitions - Like any other prediction/measure-ment tool, value engineering can be predicated on anaxiomatic set of assumptions, describing as realisticallyas possible the ground rules of the aiscipline. Value,for the present purpose, is appropriately viewed as theutility of a prcposed system equipment to the user,measured in terms of achievement of some objectiveestablished by the user. Thus value (of a thing) is theutility (of a thing) professed in achievement of anobjective. For military systems, this utility isquantifiable in terms of performance capability measures.

'T7

The term objective may be considered synonymous withthe term function as used in value engineering litera-ture.

Value engineering analysis is a quantitative and systema-tic method directed to the achievement of specifiedperformance objectives equal to or greater than somepre-assigned value at minimum resource expenditive. (Theterms value analysis and value engineering are treatedsynonymously in this report.) The term system is usedin this report as an achievable objective specified interms of performance parameters, which are transformableinto hardware and/or processes, and/or schedules.

3.2.2.1 System Value Parameters - In general, there aretwo types of system value parameters. These are shownin table 3-1. The basic value parameters are as follows:

a. Design Value Parametecs: These parameters estab-lish the design requirements imposed on thesystem. The capability parameter is defined interms of mission requirements. Each proposeddesign alternative may be predicted with respectto satisfying the parameter numeric. This wouldbe generally accomplished using modeling tech-niques. Demonstrzation testing may be conductedto ensure satisfaction of the parameter numeric,with the exception of the survivability andsafety parameter, in which it may be infeasible.

b. Cperational Value Parameter: These parametersdescribe the use value of the system. The designand use value parameters constitute the totalvalue to the United States Air Force. Specificnumerical description is to be provided by theUSAF of each design and use value parameter.

Value parameters, as defined above, satisfy quantitativerequirements, prediction, and demonstration requirements;

8

m • -

4.) (d mu) -e >

> :1e4i0 0 0 0 -4 0 90 043 . : ) rl~. ri r4 M *U4J r40 -A -

0 9r- 4 (ai 0) 0 M M d) M M4J M 4.JU(00403 d 0l~ C4 U )0 -r4 U0 $4U IVU4V000 ror . 00- 0 > r04J 0OU 0 0 f-0

0 V. 0 -rq r-4 - M4-) rU)4.)4J .I - -. 44 Hq 04 H)(1) W 0 C: -4 0) *rq H 4.)U (a

P4>4 U)> > -4 r4 -- > N iid~0>4J)4) En,~ (U4 V Mw (Dro, L 04, a

04 44) 0~ E-4 H

4-)

0 a4-H

$4 4.)

Z -r 00 4.J4J 0 *d 0H *r-I H 4.)*rE-4 4J (14.) s U)H '40(a H- ) a~ )

HH 0'4) -r-I (a fa :1 44 00 *rl N 4-) :s 4) H- 41)

cvUz A0 Ci C i) r. 0) 0 x1) ra r. (a 4) 0 q-

~ r4 H V4 E-4 E' r

4J m ) 4U)(a 4.) 0) (

F-4 J t 4 .)

04 *r-( ) )4r-d U)A n4.J4J rHo U -4a

:3 a) ý 0) o

a ) U U) -H 4.)U) rtJ, U) C) (Uj

>1 u 34)40

>14-.)

.1-4

4.) P4~ 9 uAr >4 (a0) r

a) >1 P-44J u -r >4 (0:3U) 4J 4'i -H H- u .)4J 4HN w" >~4J A 1-(U4Jd -H Hu(Ti ( 4Jr4-4(0 -H94- - aU)

r-4 AU .,1 ,O ( 4 (aO .,1 3 J-H J ( >r >,A~U N4J o-4 mO

a) tP A 4(d4 -14 4 (aUH NL U0 1 ,- 1)41 0) riU(U ( m) UH "10>w$ - 4 -1

J!: M , 44 0 4A04

rd> 1)(o ( 4 ( 0v9r

~'wp~ V 'm

and, as importantly, represents utility of the system tothe Air Force in terms of achieving an objective(s).

3.2.2.2 System Utilization Rates - The value of the sys-tem is related to the cost of the system through utilizationrates. (See table 3-1.) The prime utilization rate is the

* operational rate, viz., how much is something used. All* other rates are either part of the operational rate (train-

ing rate) or derivatives of it (maintenance rates).

3.2.2.3 Dependent Variables - The system utilizationrates, operating on design and operation value parameters,combine to determine both acquisition and support cost.Thus, for a well defined system design configuration -design and operational value parameters specified alongwith hardware implementation - the total expected cost ofacquisition and support may be estimated, using the systemutilization rates. The system utilization rates areintimately related to how the system value objective isachieved; that is, hardware alternatives. These alter-natives are in turn related to basic cost inputs ofacquisition and support.

3.2.3 Information Adequacy - At any point in the systemdevelopment cycle, the information upon which decisionsare based is in the form if estimates. Greater detailand accuracy may be obtained but only at the expense oftime and cost and perhaps national safety. To assureoptimality, information accuracy sufficient to assure thatone alternative is superior to another is all that isrequired.

From the definition of value, and its relation to totalexpected cost, it is apparent that system value can onlybe predicted with the same degree of accuracy as can bethe basic value parameters. Re-ognizing; that it is realdifferences in total expected cost which is the principle cri-terion, it is also true that information sufficient toassure that one alternative is superior to another is alsosufficient -o assure that the minimum cost goal can be achieved.This particular feature is singularly significant, in thatas the hardware configuration becomes more defined varia-tions in cost estimations for acguisition and supportdecrease. Further, for the purposes of comparing alter-natives, the points of differences between alternatives

10

____- -.--- Ti-r i wT- - i f --- -

- - -- jrj

may be singled out and, if necessary, greater detailinformation acquired.

In general, acquisition costs are best provided by thecontractor since this is the source of alternatives andbasic cost inputs. In order to project support cost asa function of design alternatives the USAF must be thesource of operational parameters and specified costconstants. The system utilization rates will be a jointresponsibility. The utilization rates are primarytarget for sensitivity analysis.

3.3 Phases of Design and Operation

The basic requirements of mathematical model or analysistechnique is that it be capable of application in thetime frame in which the problem exists and, additionally,that it be capable of utilizing information of limitedaccuracy. The refinement (closeness of fit) of themodel should be predicated upon exactness of the infor-mation processed.

Throughout the conceptual phases of system developmentdecisions are made sequentially with increasingly moreaccurate estimates of system performance and cost. Inspite of the relatively inaccurate information avail-able in the earlier stages, decisions still must bemade concerning alternatives, and to ensure that theproper alternative is selected, the methodology ofprocessing available information must permit findingquantitative differences between alternatives.

Figure 3-2A depicts the broad cause and effect relation--hips that in actual practice develops into a concatena-tion of events that terminates in a deployed and opera-tional system. The important features are:

a. As time progresses, the alternatives availablefor subsequent phases become increasingly con-strained.

b. Changes in concept at any phase can be reflectedin terms of resource cost in subsequent phases.

4J0

H. H

(DU)ý4a ý4 Wmfl 0 r4 En -r

A A

,U -P0 4- .0 W. 144

$4 W rI 4 $4-E r '444j:4 .4, E4 s: *HU 0

U)4 Z4 H4 U) Hagd a)) U) fa tjo~f CCU 0ýCl

A A

H co H HH I-4 H .4J

fa) Q S .,qm w ,

r. z fo & m: fr- 0 $4 r-4 4

> a44A A,'Ii 4 1)

H H 4U) H -r a i 1Aa) .0JU LI Ua) D ( 1)u M

U)J a) 14 C' in) 0

44 H-r ' 04 foc 4(

U) E- 4 m u o

12~

c. Input (requirements) at any phase may becategorically related to previous decisionsor shown to be relatively independent.

Figure 3-2B depicts the same phases with feedback pro-vision. This feedback is simulated in that alternativesat any phase are extrapolated into the terminal phasesof the system life cycle. The value advantage affordedby simulated feedback are as follows:

a. Minimizes constraining requirements on sub-sequent phases without tested long rangeeffects.

b. Permits relative evaluation of alternatives.

c. Permits sensitivity analysis to be performed.This type of analysis takes the following forms.

1. Determination of importance or non-impor-tance of a decision.

2. Determination of effect if a change isnecessitated in a subsequent phase oflife cycle.

3. Point up areas of high cost sensitivity.

Figure 3-3 provides a detailed picture of the systemprogram phasing. Opportunity for change exists at everyphase and at every level of system development. For"change" (PCP) read "value engineejing" and the wholestory is contained in one picture

F)

I 0

I X

-- - - ---- - I

i < • I "-=/u .

,,-,j z /I/•I

o l-l --1 . - -T --2. . "- , , -, -.ZRi ! !C- 1.

z 0 CL

/ I / • < •-÷.. .. I ---2 |

Qoot-f 0~ as

0i 0 • 00-.. -*. . .- - - a..cQ.i -. I •- • "• " I*

- ~N13Y SINWOV3 M NOIS3fOO0

o I A_< I• - - I

I'" " ~ , I I° 2 -, I .ti•

144

4 -4 ------ - ~ - ---- :--- - - -- - - -- - -

A4 ----------- ;

Z- 4--K : Z- a

a 01 5

14-

4. PROPOSED STRUCTURE

4.1 General

The methodology proposed in this report is expressly con-sistent with, and intentionally limited to, the existingDOD and USAF concept of Value Analysis; that is, achieve-ment of specified functions at minimum total expectedresource costs over the life cycle of the system. Theprogram intent is the development of a technique whichwill permit achievement of a specified objective atminimum resource cost invested.

The important differences between the orientation of theproposed technique and conventional value analysis lie inthe areas of application, The proposed technique is to beapplied in the conceptual and definitions phase; whereas,conventional value analysis is directed to after-the-factdesign analysis, generally directed to minimize acquisi-tion costs, and usually exercised under contractual incen-tive types contracts. This latter approach is quite legitimate

due to the inability to evaluate consistently the savingsthrough value engineering efforts at earlier conceptualtime; that is, how are cost savings demonstrated in theconceptual and definition phases.

The position taken on this matter in this program is, thatthe aim is not directed to reducing cost; but, statednegatively, to eliminate alternatives requi.ring unnecessarycosts bcfore these costs are incurred. Measured in thisway, a product which undergoes significant .cost reductionin the acquisition stage is poorly designed; dependingupon:

a. Did a preferable alternative exist at the timethe decision was made?

b. Does additional information exist now which didnot exist previously?

c. Was the decision made using the best informationavailable?

Is

d. Were the alternatives projected into total life

cycle?

e. Were chance events weighed and/or explored?

The methodoloGy developed in the following sections isdirected to provile the least cost alternative through aquantitative syst,?matic analysis.

4.2 Definition o:i ObiP:-ive

Let E designate a set of parameters describing the systemeffectiveness of the system under evaluation.

E="'"(el, e2, e3 -e .en)(-1

Let EO designate the set of parameters (eio) h3ving theminimtum acceptable performance numeric associated witheach parameter (greater than which there is no return ineffectiveness for the system). This set ot parameternumerics constitute the value (V) of the system.

The value engineering criterion or objective now becimes

Objective: Minimize T=A+S (4-2)Subject to E-EO

D!DO

where A = cost of acquisitionS = cost of supportD = delivery scheduleDO= minimum acceptable delivery schedule.

This model may be expressed also in the form

2 2MinF(T) =S+, 3 (A-Ao+r 3 )+A1 (E-Po-rI)

2(D-Do+r2 (4-3)

16

where:2EE

E-Eo-r2=0 E>E

D-Do+r = 0 D-D020A-A++.02 A=-A0

where:7. is a Lagrange multiplier, 18 intro-

duced to ensure the properdemensionality along with numericalvalue, and r. is a slack variablenecessary to ensure that the in-equalities are satisfied.

The importance of equation 4-3 fiom the value analysisviewpoint, lies in recognizing that variations beyondthe minimum required (ei.) may result in a very realcost reduction. Figure 4-1 illustrates this relation-ship, where e.^ is the specified numeric from thesystems studyleyond which further improvement doesnot contribute significantly to system effectiveness,and e. is the absolute minimum cost point. Mostexamp±es of cost reduction result in increasedperformance, i.e., beyond requirements. 7For example,a fringe benefit of cost reduction resulted in anincrease in reliability of 30% of Class I changes and48% of Class II changes. This implies misdirectionfrom the existing definition of value as well asvalue analysis. The difficulty arises from the tacitassiunption that achievement of a quantitativelyspecified objective at minimum cost results in theabsolute minimum cost.

4.2.1 General Value Function - The definition of valuegiven above obviates the problemia of dimensionality thathas plaqued investigators seeking a value model which per-mits establishing ratios to determine greater than or lessthan conditions. The following development shows thecharacteristics such a function must possess to satisfya ratio test, viz.

IfV1 /T 1 (4-4)

then V2 /I 2 is preferably to Vl/r 1 , etc.

F"- .

M Q)*O v

0~ 44

CU) Q)

.i4JQ r4

z. -'-

.r4 Q

:I) -- 0

4Jr 0)>U) i

4.2.1.1 Requirements of a General Value Function - Letc 2 -a2"''',n be values of parameters describing a design

a ternative and let V, a function of the parameters, bethe value of the design alternative. The function V(aa2"...-n ) is to be determined which expresses therelative value kor absolute) of the design alternative.An alternate design is described by values of parameters.

It be required that the ratio

V(al,a 21 ... ,an)/V(1 1 ,1e2 ,...,On)

be independent of the units of measurements. Then V mustbe of the form

n S.V -11 a. I where s. is a constant and independent of

Cl" Thesi is a measure of the significance of a..The exponent may be either positive or negative. Thevalues of the exponents may be determined from

Isil =ki I sjjif such a relationship can be established. This yieldsn-i equations for determining the n exponents. Given anysi, and knowing the value of kj, all others may be deter-mined.

The mcdel above is predicated on the constancy of therelationship between si and sj, e.g., speed is always twice(k=2) as important as cost. Thus this model forces alinear relationship amona exponents. Secondly, the modeldictates that an increment in the value of a parameter abe independent of the weight s associated with thatparameter.

4.2.1.2 De Probability Distribution Function - One func-tion which satisfies the difficulties of dimensionality isthe probability function. The basic requirements aresatisfied if

a. The probability density function is

p(t) -0 (4-5)

b. and the probability distribution funct:Lon is

_p(t) dt=l (4-6)

Note also, that the probability distribution function

P(t> tO) 0 fJt p(t)dt

is, of course, dimensionless.

Thus, the probability function approach does satisfy thedimensionality difficulties. The value engineeringstructure proposed in the methodology developed in thissection is completely compatible with the notion of valueas a probability function. The differences arise in thatit is assumed that parameter-values have been establishedfrom system effectiveness trade-off analysis. This per-

mits treatment of the function in disjointed form presentedin section 4.3.

4.3 Cost Analysis

The method of analysis is based on the sequential decisionprocesses, characterized by a logical sequence of events.The events are of three types as follows:

a. Feasible alternatives

b. Chance events

c. Program schedule

The a~proach is commonly treated in literature as a decisiontree.,

This sequential decision approach is analogous to dynamicprogrammii'g, in that alternatives which possess bothcontingency events and subalternatives are evaluated using

a backward evaluation process. This feature permits

significart computational reduction which otherwise could

render the technique infeasible.

20

Each sequence in the decision tree may be considered astrategy. And associated with each strategy is a resourcecost. The optimum resource cost is found by successivelyevaluating each alternative in the backward sense. Ateach common branch point, rolling backward, the more costlyalternative is eliminated.

4.3.1 The Decision Tree - The technique to be employed ismost easily grasped using the decision tree diagram. Thisis shown in figure 4-2. The circled (0) entries representfeasible alternatives and the boxed (C) entries representchance events. Associated with each chance event is anestimated probability of occurrence. Regardless of thespecific sequence chosen, each sequence results in a termi-nal event T; which, in this case, represents a completedefinition of a proposed hardware configuration of the sys-tem, complete with the cost (C) of the alternative. Thesequential decision tree may be considered the sequence ofincreasing definition of the hardware design, the branchesrepresent alternate design approaches at successivelygreater levels of hardware definition.

A I• Evai. of n tai Alprnateq - The first step in

the evaluation process is the establishment of feasibility.Specifically, two types of constraintE must be met. Theseare, from the basic definition of value of section 4.2.

a. T iTo

Tin time required to implement the strategy

b. Eo

Here Ti may be established using a PERT project techniqueand E is established using either the standard predictiontechniques (reliability, maintainability, etc.) or a pre.diction model specifically developed for the specific sys-tem parameter.

The second step in the process (having eliminated thosealternatives which do not satisfy either or both con-straints above) is the estimation of the total resource

21

S r- -- . .,II'- -- - .....

o"% -f% 0-% .-O -%i (N (Y ~) U U u Ho a -

N N

H (N N N (N(N (N (N ( H (N N

(N

HH

H r) r-

Hl " H H4 AHa Ha Ha HE-1N

N(

H C40P4

N N H N

04 (

HHH0

040

H 22

cost. This may be accomplished using peculiar contractorcost accounting or PERT/COST techniques. Starting fromthe terminal points having common branch points, the morecostly alternatives are eliminated. This procedure isreiterated until only one alternative remains. The degreeof accuracy involved in the costing analysis should beguided by the relative magnitude requi red to demonstratethat one alternative is superior to the other.

4.3.3 Value Analysis in the Continiuous Time Domain - Manydesign alternatives will be relatively simple decisionswhereas others may be more complex. The simpler evalua-tions will generally involve only acquisition cost, therebeing no essential difference in value parameters, oralternately, only differences in support cost. Anotheraspect which characterizes these simpler evaluations willbe the independence of subsequent decisions involving thesystem. However, in general, particularly of the moreimportant decisions, the sequential aspect of the decisionswill predominate. The question quite naturally arises ofthe feasibility of beinq able to completely define aparticular configuration during a preceding system concep-tual phase. The practical aspects of this question areavailable time, cost, and information adequacy. Recogniz-ing that as the hardware becomes more defined, decisionsinvolving changes or modifications become relatively lessimportant than the decisions made at a previous stage.Further, cnly sufficient information to ensure that thebest of the feasible alternatives is selected is required,thus information is required only sufficient to ensuredominance of one alternative to another.

4.3.4 Method of Application - It is important to recognizethat it is unlikely that equations will ever bedeveloped which extrapolate design value parameters in con-junction with operational value parameters into exactsupport costs. However, from the viewpoint of value analy-sis, it is not necessary to possess such comprehensiveequations. What i3 necessary is the ability to evaluatealternatives via cost/performance differences.

23

The cost methodology aspect of value analysis is of primarysignificance, since any unrequired sophistication and/orinformation and documentation may offset advantages offeredby the technique.

The proposed approach is advantageous in that it permits individualcontractors to use their own cost accounting systems. Theonly requirement is the ability to differentiate betweenalternatives as measured by acquisition and support cost.

4.4 Detailed Cost Procedure

The total cost (T) of a system, equipment, etc., can be

represented by

T=A+S (4-7)

where

A=the cost of acquisitionS=the cost of operation and support

Th cc.t Z bas• .0i tas -%- -d -ifetime cost, Figure4-3 shows the basic cost model which has to be evaluated.Each element would ordinarily be evaluated to obtain thetotal cost. For purposes of reaching a decision orwhether to accept a particular alternative, differences intotal cost are employed. Thus, it is unnecessary toevaluate equivalent elements of the two alternatives whenconsidering which one of two to choose. It is necessaryonly to evaluate the elements that are pertinent to aparticular decision.

Let

T =total cost of the first alternativeT =total cost of the second alternative

the difference in total cost (AT2 , 1 ) is represented by

T 2,1 UT2"T1 (4-8)

24

S44 I

041.

-COr14

;g 4

"Id U. I4

040

U1- 1 2 T-

w Apw

where elements of cost common to the first and secondalternatives need not be considered if they are equal.If the quantity AT2 1 is negative, it means that thesecond alternative is less costly. If positive, it meansthat the first alternative is the correct choice, viz.,less costly.

Once two alternatives have been compared, the one yieldingthe lesser cost advantage is dropped from further considera-tion. Successive alternatives are devised and matciedagainst the current alternative that has greater costadvantage.

4.4.1 Cost of Acquisition - The elements to be consideredinclude all charges which may arise from the design,development, fabrication, and installation of the equip-ment.

Particular attention should be paid to items which markthe differences between otherwise similar alternatives.Among these may be:

a. Built-in fault isolation features

b. Special test equipment

c. Special tools

d. Facility of manufacture

Differences in research, development, design, or hardwarecosts shoulC be considered where they constitute a signif-icant difference among the alternatives. Differences inrequirements for government furnished equipment (GFE)should also be established. In any case, refined estimatesof costs are justified only when the alternative, or groupof alternatives, has cost or o%.hcz advantages which makeit a good candidate for selection.

Cost of acquisition (A) can be represerted b,:

A=CD+CF +CI+ CM+ T+CX+CL

28

where

CD=COSt of design

CF=COSt of fabricationC1 =cost of installationCM=cost of manualsCT=COSt of test equipmentCx=cost of tools and fixturesCL=COst of line item documentation

These costs have been tentatively identified in sectionthree and will be considered, and further refined, inphase II of the program.

4.4.2 Cost of Operation and Support - The cost of opera-tion and support (S) is represented by

S=C +Cf+Cd+Cy (4-10)

where

r =cAn* at trmani7Aen

Cf=cost at fieldCd=cOst at depotCy=cost at factory

4.4.2.1 Cost at Organization - The cost at organization(CO) is represented by

Co=Ccm+Cof+Cos+Cot (4-11)

where

ComaCOSt of personnelCof-cost of facilitiesCos8 cost of sparesCot-cost of transportation

4.4.2.2 Zost at Field - The cost at field (Cf) isreptesented by

CfmCfm+Cff+Cfs+Cft (4-12)

27

T ~-- ~ ~

wl'ere

Cfm = cost of personnel at fieldCff = cost of facilities at fieldCfs = cost of spares at fieldCft cost of transportation at field

4.4.2.3 Cost at Depot - The cost at dept-t (Cd) isrepresented by

Cd = Cdm+Cdf +Cds +Cdt +Cdu+C . (4-13)

where

Cdm = cost of personnel at depotCdf = cost of facilities at depotCds = cost of spares at depotCdt = cost of transportation at depotCdu = cost of utilities at depotC1 = cost of line item at depot

4.4.2.4 Support Cost at Factory - The total cost offactory (C ) will vary so much with the type of labor tobe employeý that no attempt will be made 'o estimate thecost.

Repair at factory is rare; however, special conditions maym&ke it appropriate in some cases. Repairs may be made atthe factory rather Than at the depot for several reasons.Most instances are accounted for by one of thz following:

a. Rare skills and/or expensive special test equip-ment are required to perform m3intenance, e.g.,gyroscopes and some other sealed assemblies.

b. Demands for maintenance exceed capacity at depot(as limited, for example, by employment budget)and factory charges are not far in excess of depotcosts.

2S

In both of these instances, costs associated with perform-ing the work at the factory generally should be about thesame or less than would be incurred if the work were doneat the depot. Otherwise, the work should be scheduled forperformance at the depot.

In general, factory maintenance is not planned as an inte-gral part of maintenance policy. Requirements for self.-sufficiency of the military generally preclude planningon factory or other contractor maintenance of criticalequipment. Where it might be planned (as in a above)experience and/or estimates from the probable contractorshould provide adequate cost figures for use in comparisons.Detail costing becomes less important in fixed price con-tracts, favored type today, as contrasted to cost plusfixed fee and similar types common in the past. Conse-quently, no detail breakdown will be made for estimatingcosts of factory maintenance in the few situations whereit is applicable.

4.4.3 General Evaluation Procedure - Figure 4-4 illus-trates a tabular procedure for evaluating each element ofthe cost model. Provision is made, in figure 4-4, for theevaluation of two alternatives. Only the elements thatchange, from one alternative to the other, wiLl be required.Once two alternatives have been evaluated, th3 one yieldinga cost advantage is retained, and the other alternative isno longer considered.

11 h m m • ] i]•[ [[ u •m[ ] J i m i ]1 29

ri E-4l

I

Sr, j 4. _ .4-

A u

tt 0 41

t .

_-_.. ... __ .... .. .... . ... -

a I' 0 - .- 0

1 4

I I

it

C 30- .-J" "'I + " "

'0. • • 8 ..

20

5. SUMMARY

The proposed value analysis technique developed insections 3 and 4 has been shown to possess the followingcharacteristics:

a. Quantification of value consistent with estab-lished USAF specification of system utilization.

b. Value parameters which are predictable andmeasurable.

c. Systematic method of quantitative analysis whichpermit practical optimization in the least costsense consistent with system value.

d. Technique structure which permits design tradeoffof discrete alternatives relating to cost and sys-tem value parameters.

e. Method of cost analysis which permits optimizationwith respect to total cos-., and is consistent withboth design and operational value parameters.

f. Method of cost analysis based on differenceprinciples which permits decisions through domi-nance of one alternative to another.

g. General method of analysis which permits cost intime and singling out areas significant costdifferences between alternatives.

31

6. PLAN FOR PHASE II

6.1 General

The structure of value as developed in section 4 indicatesthe most fruitful areas of exploitation of the methodology.This comes about primarily as a result of the strict causalrelations between system value and the total expected costdifferences. Consequently, the major direction to betaken in the-Phase II will be a general refinement andexpansion of the value analysis methodology. (See figure 6-1;

6.2 Structure

The areas of refinement and expansion will be as follows:

a. Detailed breakout for acquisition cost specifi-cally related to conceptual and definition phases.

b. Detailed breakout for support cost specificallyrelated to conceptual and definition phases.

c. Expansion and refinement of technique to handlechance events. Some work has already been donein this area but involves making estimate. ofprobability.

d. Development of causal relations between valueparameters, system utilization rates, and totalcost differences.

e. Development of detailed information requirementsto be supplied by the USAF for support costanalysis. This would include a delineation ofdeployment and self-sufficiency constraints.

6.3 Validation

RCA proposes to validate the value technique developedunder Phase I of the contract in the following manner.

32

U2

10

4.))

La 41

0i

0 - - , >1 a

.4.

.4-)

4-)

0) 4- 4(D 4.)

a) 0 0 >

u H 4) '

o4 F4 to 0

"4 094 m

U)) H 0

$4.P''4 H- F4 P4 m a

z lo m) 0 r- .. 4 t

4)l ) f

33

-4--"

Vo-0

S6.3.1 Establis'ment of Errors - Establishment of errorsources, anticioated error magnitude, and error boundson the following aspects of the technique.

a. Capability of projecting design alternatives

accurately into the support cost differences.

b. Capability of controlling acquisition cost.

c. Capability of forming a near minimum cost initialproposal.

d. Capability of performing within schedule con-straints.

e. Capability of singling out tradeoffs betweendesign, manufacturing and support costs.

6.3.2 Mode of Application - RCA proposes to use atleast the following examples to illustrate the mode ofapplication of the techniques.

a. Production Design Phase - Selection of wirewrapping process for MINUTEMAN.

b. Program Definition Phase - Selection of realtime computer redundancy configuration forcomplex mobile missile system.

c. Proposal Phase - Several examples of costminimization in a competitive environment,incorporating cost control check points insequential phases, ard involving tradeoffsbetween engineering an. manufacturing.

6.3.3 Discussion - Although the validation above will notconstitute a substitute for several test vehicles followedthrough the entire life cycle, it will establish fem'sibi-lity of implementation. The proposed approach to valida-tion is due to lack of information on previous,,, designedsystems; plus, the inability to project the requirementsfor testing and field use for systems that aro presentlyin the design stage.

Approaching thc validation in the manner proposed willtest the technique for selective application acros.product lines along with decision making capabilityas related to program phasing.

34

C.3.4 Critical Points - The critical points of the vali-

dation will include the following:

a. Information availability and adequacy relative to

1. Design value parameter

2. Operational value parameter

This will provide a critique of informationadequacy as a function of the conceptual phasesconsidered.

b. Computational problems in technique application.

c. Ability to project cost differences in bothacquisition and support as a function of alterna-tives. This will permit:

1. Testing for the principle of dominance amongalternatives.

2. Singling out sources of error in cost esti-mation.

d. The quantitative predictability and measurabilityof the system value parameter will be evaluated.

6.4 Iwplementation

The scheduled validation of the developed value analysismethodology will constitute a practical test of the imple-mentability of the technique. The proposed technique isprima facie implementable from the basic structure, giventhe basic information required for decision making.Anticipated difficulties will invariably pivot aboutinformation availability and associated uncertainty.

The key to successful application of the technique willrest on the detection of potential cost affected areascoupled with the ability to eliminate, systematically,the more expensive alternp*4 ves. The proposed structurepeLnnits the latter. The first point will be satisfied,in the second phase of the program, by providing detailedcost element breakouts and cost projection techniques.

-4S

Ii

BIBLIOGRAPHY

1. L. Ivan Epstein, "A Proposed Measure for Determiningthe Value of a Design," Operaticn Research, April 1957.

2. Peter C. Fishburn, Decision and Value Theory, JohnWiley & Sons, New York, 1964.

3. R. E. Purvis and R. L. McLaughlin, Validation ofDiscard-at-Failure-Maintenance Mathematical Model,RADC-TR-65-214, June 1965.

4. Value Engineering Handbook, Hill, Office of theAssistant Secretary of Defense (Installations andLogistics), March 1963, Washington, D. C. 20301.

5. Principle and Applications of Value Engineering,Training Guide, OASD(I&L), Washington, D. C. 20301,AD604663.

6. The Management of Value Engineering Programs inDefense Contracts, Training Guide, OASD(I&L),April 1964, Washington, D. C. 20301, AD604662.

7. Instructors Notes for 5 and 6, AD609883 and AD609884.

8. Harry 0. Huss, Value Analysis (Value Engineering),December 1961, U.S. Army Chemical-Biological-Radiologi'al Engineering Group, ENG No. SR-i, AD609520.

9. Introduction to Value Engineering, Defense ElectronicsSupply Center.

10. Value Analysis-Value Engineering, The Impiication forManagers, American Management Association,

11. Value Analysis in the RCA Cost Reducuion Progiram, RadioCorporation of America, Camden, N. J. 08102.

12. Lawrence D. Miles, Techniques of Value Analysis andEngineering, McGraw-Hill Book Company, Inc., 1961.

36

13. Value Engineering, Logistics Management Institute,May 1963, Washington, D. C. 20016.

14. Weapons Systems Effectiveness, Industry AdvisoryCommittee (WSEIAC), AFSC-TR-65-1 thru 6, January 1965,Air Force Systems Command.

15. Air Force System Command Manual, Systems Management,AFSCM 375-1, 3, and 4.

16. Armed Forces Procurement Regulation, Part 17-ValueEngineering.

17. Fringe Effects of Value Engineering, DOD, ValueEngineering Committee of the American OrdnanceAssociation, May 1964, Washington, D. C.

18. W. S. VanDorn, On Lagrange Multipliers andInequalities: ORSA, Vol 9, No. 1, 1961.

19. P. W. Bridgeman, Dimensional Analysis, YaleUniversity Press, New Haven, 1922.

37

APPENDIX

LITERATURE SEARCH

1. INTRODUCTION

The bibliography included is a selective one representingthe present state-of-the-art in value engineering. Duringthe literature search over 100 documents were examined; ofthese, the seventeen documents, included in the bibliography,were considered to represent the thinking currently in voguewith value engineers and represent the state-of-the-art.

2. SHORTCOMINGS OF STATE-OF-THE-ART

Several shortcomings permeates essentially all literaturereviewed. These are:

a. Value/Job Definition: Generally value is definedloosely as getting the job done at least cost; how-ever, invariably there is only a loose tie withhow the job, as described, relates to the value ofthe end product, viz., accomplishment of mission.

b. Support cost and extrapolations to support cost is,at best, given only lip service. There has beenno real attempt to evaluate, systematically, totalresource cost variation as a function of design/develcpment alternative selection.

c. Most examples of cost reduction result in ircreased?erformance, i.e., beyond requirements. Thisimplies misdirection from, the existing definition ofvalue as well as value analysis. The difficultyarises from the tacit assumption that achievementof a quartitatively specified objective at minimumcost results in the absolute minimLum cost.Figure 0-1, in the text, illustrates this.

35

- a-•

d. Value engineering techniques, as they exist now,are exclusively oriented to acquisition oroperation phases rather than the conceptual ordefinition phrases.

39

A if--

UNCLASSIFIED _ _ _

Security Classif;patipp

.0 -UM1Ifl C0NTPOL PrATA. PA!."c'atyfr cif.If4fifsaor of "14-, bogy of fltrf Ib r Infp;•ng pnnqlmttqp mus.t bo eonspio vo Ike over*## topo # cl o*1iafied)

T GKIGIKATIN 4 ACTWITY (Co~pordlf "Iflu #a.~ RWP4PT 1mgun.,v C LANSIPICATIONRadio Corporation of America UNCLRCA Service Company Division lb GRo,

Alexandria, Va. 22314 _ . ................ . .. .. .3, WONT TTLK

Criteria for Value Engineering, Phase I, Feasibility Study

4. DESCRIPTIVE NOTq (Typ of Iport anp #@eklsvov datee)luterim Report Jul 1965-Nov 1966

5. #UTIOP(O (Lo "de o n *. ijun, neo,, InitiI)

Purvid, R. F.McLaughlin, R. L.

pI. g poR Q#•7. ! 7 91+A7 N-, 09 o Af E -- *"0. OF RMaor

February 1966 39 _ NoneA.4. CONTRACT OR 6PANT N•. 60. ORIiINA"4'@8'I 9PO@RT NU•I•Iws)

AF 3(602)-3•50

c.Task Nr. 0 h- .55?L9(J.L""II. _ _RADC-TR-65-475

10. AV II.:ASILTY/1MITAAIG N I .. . . . .

Distcibution of this document is unlimitel.

-;I. SUPPLE;dPNTA. Y 0Tl" 13n. P@o4iomGRN MILITARY ACTIVITYReliability BranchEngineering DivisionRime Air Development Center, GAFB, N. Y.

This report E.mzwarizes the state-of-the-art of Value Engineering. Aproposed struc;ure 2n7 a general value analysis technique alo-g withquantification of value Is presented. Based or the proposrd structurea general methcd fcr resource cost optimization is developed.

DD ,j?, 1473 UNCLASSfitr)e.CU V Classification

SecurityCleassfication________________14. I-INK A LINK U LINK C

KYWMSROLE WT ROLE WT ROLE "I'

System/EquipmientDesignCost/EffectivenessPerformanceOperations ResearchValue

________----I-INSTRUCTIONIS

1. ORIGINATING ACTIVITY: Enter the namte and address imposed by security classification, using Standard statementsof the contractor, Subcontractor, grantee, Department of Do. such as:tense activity or other organization (corporate author) Issuing (1) "Qualified requesters may obtain copies of thisthe report. report from DDC."2a. REPORT SECURITY CLASSIFICA~rION: Enter the over. (2 "Foreign annotincement and dasseminstion of thisall security classification of the report. Indics'-ý whether rpr yDCi o uhtz("Restricted Data" is included. Marking is to be in accord.. eotb D sntatoie.ance with appropriate security regulations. (3) "1U. S. Government agencies may obtain copies of

2b. ROU: Atomticdowgraingis pecfie inDoDDi-this report directly from DDC. Other qual~lIed DDC2b. ROU: Atomaic ownradig i spcifid I DO D1users shall request through

rectlve 5200. 10 and Armed Forces Induastrial Manual. Enterthe group number. Also, when applicab'e, show that optional-markings have been used for Group 3 and Group 4 mas author- (4) "1U. S. military agencies may obtain copies of this

ized. report directly from DDC. Other qualified user.3. REPORT TITLE: Enter the complete report title in all shall request throughcapital letters. Titles in all cases should be unclassified.

I'a meaningful title cannot be selected without classifico-tion, show title classification in all capitals in parenthesis (5) "All distribution of this report is controlled Qual-immediately following the title. ified DDC users shall request through4. DESCRIPTIVE NOTES: If appropriate, enter the type of ____________________

report, .~.g. * interim, progress, summary, annual, or fina~l. If the report has been firnithed to the Office of TechnicalGive the inclusive dates when a specific reporting period is Services, Department of Commerce, for sale to the public, indi-I covered, case this fact and enter the price. it known.S. AUTHOR(S): Enter the n ime(s) of author(s) as shown on IL SUPPLEMENTARY NOTES; Use for additional explana-or in the rep-nrt. Entet liast name, first name, middle initial,. oyRlsIf rmilitary, show rank rond branch of service. The name ofthe principal ..:'thor ia an absolute minbiaum requirement. 12. SPONSORING MILITARY ACTIVITY;~ Enter the name of

the departmental project office or l aboratory sponsoring (par'6. REPORT DATE. Enter 'he date of the report as day, :ng for) the research and development. Include address.month, year; or month, year. If -note than one date appearson the report, use date of publicationt. 13. AFISTRACI; Enter an abstract giving a hrief said factual

summary of the document indicative of the report. even though7a. TOTAL N'UMBFiý 0" PAGES: The total page cou nt it may also appear elsewhere in ihe bod% of the te,?hnical re-should follow normal paginatior. procedure%, i~e., enter 'he port. If addittonal space is required, a continuation 'sheet shallnumber of prges containing intformation, be~ attachted.

g 7b. NURL.,I'R OF REFERENCES: Enter the total number of It is highly desirable that the abstract ut classified reportsreferernces -itvd in the report. ,Cunclasatfied. Each paragraph of the alsetrect shall end withBe. CONTRACT OR GRANT NUMBER: If appropriate, enter . luidicattion -f the military z-o~utity classification of the in-the applicahle number of the contract or great under which forrra~ic'n in the paragraphi. reprsesnted as (T'S). (3). (C), er (11)06t report Wa- written, Th.Pre is no limitattio'.itelngho h bar.Hw8b. Or. & Id. PROJECT NUMBER: Litter the appropriate ever, the suggested lengpý from ISO tl' 22S words.military department identification, much as project "umber. 1 E OD:Kywrsatt~nctymaigu emsvbproject number, system numberu, task number, etc.. rsotprssta hr.Ire~~~nadmyb sda

go. ORIGINATOR'S REPORT NUMBER(S)- ErAwe the offi- index ewitmes l~t t-iatl"gin the re-port. Kev words must becial report n-imboi tiv which the document will be identified selectvd so that n0 security ,lessaI'caori &u require~d. Mdenu,ank4 controlled b) the origtinating activity. This number Imost tiess suvh do oquipmcnt model deaagpdtiort. trade name, militarybe uni~que to this reptrt. proJect code news.. geogiaphic location. m~ay be used as hay

iQb. OTHEFR REPORT NUMBER(S): It the report has bei words '3ut will be followrd by 4" indication a tofechnia-al con.

asigned any other retoart numbers (eithor by the origtriator let h ainmont of 1i44%, rulcadwihsi pinlft by the sponsor), also enter this aIsimaibrts).

10. AVAIL ABILlT Y'LlWTAT ION NOTICES& Entpe any lire'itwtrona on further disevaminstiori of the report, other than lhoie.