Original Post Date: Wednesday, October 10, 2012

Recently I wrote a blog on the “Role of Value Engineering in Affordability Analysis.” In that blog, I wrote about the importance of understanding the cost behavior of each candidate's (alternative) architecture as part of the Value Engineering method in order to achieve affordability. I defined “cost behavior” as the relationship of how cost varies as design factors such as new materials, cutting edge technology, new manufacturing processes, and extensive support requirements associated with a particular function causes a cost to change. What are the drivers and how does cost change as those drivers are manipulated. However, it is not sufficient just to understand the design to function relationship between design factors and how that will impact cost. There is a time-based component to this relationship which is driven by the activities and products associated with the system development life cycle.

The primary focus of Value Engineering is assuring that the greatest functionality is provided for the least cost or expense, to maximize value. I personally defined value as a ratio or relationship of cost to function. But I also believe that this definition alone is not enough. OK why isn’t a calculation of design factor change to cost variance not enough to determine value? It is not enough because I believe value will change over time. Why do we have to include a time component?

Figure 1 VE Within The DoD System Life Cycle

The Figure shows the temporal application of Value Engineering in relation to key Systems Engineering DoD Technical Reviews and required Affordability Assessments.  It is the author’s contention that the value of a function within a system will change over time with each technical review[1]. I believe this to be true because the design matures with each subsequent review and with each review the actual performance of a function is better understood. As the performance of the function or system become more evident through the testing and analysis associated with each review the value a decision maker, in the case of DoD Systems the warfighter, has for a function / system changes over time. There is a subliminal value calculation that goes on in the head of the decision maker. This calculus is associated with the concept of incorporating the stakeholder’s preferences via the application of a personal set of weights attached to a set of decision criteria. The weighting is the quantification of the relative importance of one decision criteria versus another. It is the conscience or sub-conscience application his personal weights that the decision maker uses to make judgments regarding benefit. The cost of a function being analyzed becomes a juxtaposition measure of value to the level of performance achieved. But this is an elusive concept. How will a decision maker determine if the function being evaluated is worthwhile or not and to what degree? What means of value judgment of function to cost is to be used? Value Engineering will assist in helping set boundaries around this question.


[1] Reviews

Initial Technical Review (ITR)                                         Alternative Systems Review (ASR)

Systems Requirements Review (SRR)                           System Functional Review (SFR)

Preliminary Design Review (PDR)                                  Critical Design Review (CDR)

Post-PDR Assessment (Post-PDRA)                                             Post-CDR Assessment (PCDRA)

Test Readiness Review (TRR)                                         System Verification Review (SVR)

Functional Configuration Audit (FCA)                          Production Readiness Review (PDR)

Operational Test Readiness Review (OTRR)                 Physical Configuration Audit (PCA)

Technology Readiness Assessment (TRA)                    In-Service Review (ISR)