Preparation and Operation of a Workshop
Insuring VE Success
J. Jerry Kaufman
J. J. Kaufman Associates, Inc.
The key to successful VE projects is
preparation. In a discipline that stresses the importance of information,
Value Engineers should not be too quick to jump into a project and attack
cost without knowing and defining the root cause problem or opportunity.
This paper focuses on the importance of
problem definition, determining value adding attributes and advanced
project planning before starting a VE task team project. This activity,
called the "Pre-event" phase, requires the VE manager to meet
with the Project Sponsors to discuss and clearly define those issues that
determine the success of a VE assignment prior to the event. Each part of
the pre-event phase is discussed describing how those parts contribute to
achieving a successful VE venture, responsive to the needs of project
management. Case study examples are included describing the application of
the pre-event phase.
When Value Analysis gained popularity in
1945, the methods of managing business in industry were much different in
the United States than they are today. Component cost reduction was an
effective and popular way to improve value. Manufacturing labor was the
dominant business expense factor. Companies accumulated massive amounts of
labor data to analyze, dissect, restructure and categorize labor costs.
Learning curves, economy of scale and material flow were key elements in
the drive to reduce labor’s contribution to product cost. Direct labor
and material cost management determined the success of a product and
therefore, the company.
The rapid developments in communications
and manufacturing technology changed the manufacturing environment. In
today’s world, bigger is not necessarily better. Compared to the
manufacturing environment 30-40 years ago direct labor and material
expenses occupies a much smaller part of total product cost and continues
to shrink. Economy of scale has given way to flexible manufacturing
techniques where lot sizes and set-up expense are no longer major cost
In response to the changes in the
manufacturing environment the focus of VE shifted from the labor and
material components of unit product cost to the cost of producing
products. This is not to say that reducing direct product cost is not
important. Product cost reduction is still an active and popular VE
venture, but reducing the cost of doing business and associated non-value
adding activities, while responding to market requirements, is proving to
be much more important in determining the success of a business.
Responding to this opportunity requires
that Value Engineers pay much more attention to identifying root cause
problems and addressing marketing issues that go beyond the direct cost of
THE JOB PLAN
Applying Value Engineering (VE) to more
complex issues then component cost reduction requires more information to
clearly define the problem, define success and structure the VE event to
accommodate those factors. Resolving these issues requires another step in
the conventional "Job Plan" which will be called "The
Pre-event Phase." The activities within the Pre-Event phase describe
the planning and resolution of issues that must be resolved prior to the
start of the VE Task Team’s project to improve value.
The Pre-Event Phase encompasses a series of
steps to define, confirm and plan the VE project. By design, the building
block steps of the Pre-Event Phase acquires and processes information in a
dependent sequence manner. The activities described in Table 1 help the VE
Task Team test the information received and resolve any conflicting
information before launching into the VE project. Each of the activities
described in TABLE 1 has a technique or tool associated with that
Table 1: The Processing
|Define the problem (or opportunity)
separating cause from effects.
|Establish goals that, if
accomplished, will resolve the problem issues.
||Goals and Objectives
|Define attributes that identify
market driving value adding characteristics
||Product Performance Profile
|Identify perceptions that are
standing in the way of achieving the goals
|Determine disciplines needed to
explore creative alternates
|Collect information by disciplines
that relate to the project issues
Problem with Problem Solving
The Pre-Event process begins with
identifying a problem or an opportunity that needs resolution. Inherent in
the VE process is the need to confirm that the problem described is the
"right" problem. There are many problem-solving techniques to
choose from. The problem with most problem-solving techniques is that they
accept the stated problem as the real problem. Problems are usually
expressed as symptoms, or the effects of the problem that is bothering the
problem definer. Problems expressed in this manner usually describe the
solution, or the symptoms instead of the problem. Consider also that
suppressing symptoms, or choosing paths around problems, often results in
the root problem emerging in another forms, often with greater magnitude
than the original problem.
Peter F. Drucker, noted author, business
analyst, professor, and founding father of the discipline of management
once said that he would "much prefer to arrive at the wrong solution
to the right problem than find the right solution for the wrong
problem." And John Dewey’s observation that "a problem well
defined is half solved" stresses the need to invest the time to
uncover the root cause problem.
Defining root cause problems for
interdisciplinary teams to resolve is particularly important in VE. Each
team member representing a unique discipline will bias the input
information to fit the discipline represented by that person. The engineer
will modify the description of the problem to comfortably fit his
discipline, as will the finance, quality, manufacturing, and other team
Another interesting dilemma is that
managers having trouble identifying, or articulating the root problem will
often describe the problem as cost related. "Cost reduction"
they say, "is our biggest problem and we must take all steps to
aggressively reduce cost." On the contrary, cost reduction is not
a problem; it is a solution to a problem. Very often managers can
trace the need for cost reduction to declining sales, lower profits,
eroding market share, time to market, late product introduction,
competitive pressures or other business conditions. The effective use of
VE requires that the team clearly understand and agree to the target
problem so that they can focus value improvements on that problem.
Consider also that cost reduction may contribute to the resolution of the
problem, but by itself, may not represent the best resolution option.
Value practitioners fully appreciate that
the success of products and services in the market place is dependent on
offering functions for which customers are willing to pay. The value
practitioner also realizes that those functions are not readily apparent.
To aggressively attack cost without knowing which functions and attributes
are "customer sensitive" could result in dramatic cost
reductions, but those actions could also adversely effect sales.
A seemingly successful VE cost reduction
project to reduce the unit cost (and price) of a line of thermocouples did
nothing to reverse the downward trend in lost sales and market share. A
follow-up project analysis found the root problem was not the price
charged for the product, but the time it took to respond to an order. A
second VE project focused on improving the order entry process and
reducing the time from receipt of an order to its delivery. The resultant
reduction in order response time, from two weeks to three days, achieved
the sales recovery objective.
The City of New York employed VE to reduce
the eight plus years it took to refurbish and modernize high schools.
Before beginning the process the team discussed the problem in terms of
seeking time saving measures. When the problem was better defined it was
determined that the eight year restoration was the symptom, not the
problem. They discovered that the problem was that no single individual or
department took responsibility for the complete project. There was no
single point of responsibility or accountability for the "turn
key" management of a high school refurbishment project. Therefore,
each participating department considered their part of the project a low
priority activity. Armed with a better problem definition the VE Team
focused on organizational issues and created a project management
structure. The result, confirmed by a follow-up audit, reduced the
restoration time by more then 50%.
The questions asked to discover the problem
may seem simple, but often generates intense discussion between the
project sponsor and the VE team to arrive at an acceptable answer. The
"What is the problem (or
opportunity) we are about to resolve?"
"Why do you believe this is a
"Why do you believe a solution is
necessary?" or, another form of this question is
"What is the consequence of not
solving the problem?"
When asking the first question, most often
the answer will fit the second question. If this occurs, the problem as
described is an imposed solution, symptom or effect of the problem, rather
than the root cause.
As an example, when asked what problem the
sponsor wished resolved, the answer was "cost, the cost of our
‘super widget’ is too high which is adversely effecting the sales of
our entire line of widgets." Applying the answer to the second
question, ("Why do you consider this a problem?") seems to be a
better fit. The problem owner was ask why the cost of widgets is
considered a problem since there was no appreciable increase in widget
cost over the last few years, the answer was "Our competitor has
lowered their price which has resulted in lost sales, market share and
On examination the problem owner’s
response as to why cost reduction was the problem, the problem was defined
as, "lost sales due to competitive price pressures." With this
new information, the sponsor agreed to the answers to the three questions.
"What is the problem (or
opportunity) we are about to resolve?"
Our competitor has recently reduced the
price of their product offering that directly competes with our widget
"Why do you believe this is a
Maintaining the price of our Widgets has
resulted in lost sales and revenue. If we respond by reducing our price to
meet competition, without reducing the cost to produce the product, it
will result in lost profits. Protecting our profit margin can adversely
effect sales and market share.
"Why do you believe a solution is necessary?"
If Widget sales and profit margins are not
protected, the business plan objectives will be adversely affected which
could result in downsizing and effect company growth.
By restating the problem conditions the
problem was redefined as competitive pressures, not cost reduction. Cost
reduction is not a problem condition, it is a recommended solution to
resolve the problem. Reducing the cost of the widgets seems like the
obvious approach, but other approaches may exist that are better. Also,
reducing product cost without protecting customer sensitive product
attributes could have a negative sales effect. Searching for ways to
improve competition offers a much broader range of study. Some additional
avenues to explore are; thinning out the loosing end of widget models,
better distribution and delivery methods, improving product yield,
increasing inventory turns, reducing manufacturing process time, enhancing
value adding product features and attributes (such as, performance,
quality, service, etc.) that will support a competitive price difference,
to name a few.
The resultant VE actions do not necessarily
have to match the competitors price reduction. Improving value-adding
features can justify and support higher prices if customers’ perceive
those improvements as worth the price difference.
With the resolution of the problem
statement, the pre-event participants select goals and objectives that, if
achieved, will resolve the problem . Using the example above, the team can
consider business and product performance Each attribute must be self
sustaining. That is, changing one should not effect another attribute. As
an example, "Unit Cost" and Labor Hours" are dependent
attributes, because changing labor hours will goals. In addressing product
performance goals, a comparison of widget features and attributes to its
competitor’s product will expose competitor weaknesses and widget
strengths that the team could study as value adding proposal candidates.
Wherever possible, aggressive and
quantitative goals are set. Once the sponsors brief the VE task team, they
should allow the task team to participate in setting project goals.
Experience has shown that goals set by the VE task team are more
challenging than those set by the Project Sponsors or the Executive Review
or "best" are meaningless terms in setting goals and should be
avoided. To optimize the widget performance or maximize the widget’s
cost-to-price ratio does not offer a clear target for the team. Subjective
terms in setting goals can be widely interpreted by the team members and
project sponsors. Some goals are difficult to express in quantitative
terms. Attributes such as "ease of use" and "customer
satisfaction" are hard to measure, but valid as value adding
With goals in place, the project’s
attributes are selected that best identify those key characteristic that
are important to the market success of the project and in support of
business goals. The attributes are then evaluated, graded and graphically
illustrated in a star diagram, to guide the team in determining where
lower valued attributes can be traded for higher valued attributes.
The requisite for selecting attributes are:
- All attributes should be independent of
each other. As an example, "Ease of Manufacture" directly
effects "Unit Cost."
- Attributes should be scaleable, rather
then binary. That is, attributes should be acceptable within a range
of "goodness," rather then being in, or out of compliance.
- Attributes can be mixed to reflect
business as well as market value adding characteristics.
The selected attributes are prioritized and
graded using a "Paired Comparison" process. Grading the
attributes ranks them in descending order of importance by determining a
percentage grade, or "weight" for each attribute. The sum grade
value of all the attributes will always equal 100. With the attributes
weighted, the team can explore ways of trading lessor valued attributes
for those of higher value during the "Planning" (or Evaluation)
phase of the Job Plan.
A minimum of five and maximum of eight
attributes are recommended for each team project. Exceeding eight
attributes will result in a difficult balancing act in determining
trade-off options. Fewer then five attributes could place too large a
weight difference between attributes that could place undo importance on
that attribute in selecting a proposal option.
Certainly "product cost" is an
important attribute in our simple widget example, but how important will
depend on an investigation of the project issues, other goal related
attributes and their relationship to achieving the "competitive
advantage" primary objective. Other attributes, selected from a wide
variety of options in addition to product cost include; Quality,
Performance, Packaging, Weight, After Market Support, Maintainability,
Ease of Use, Delivery, to name a few.
The case study selected to illustrate the
process describes how a Product Performance Profile is developed using
attributes. The case study involves a manufacturing company that produces
steering systems for the automotive industry. The VE study involves a new
steering system that has an estimated production cost far in exceeds of
the acceptable market price for the design features of the system. The
name of the company is omitted and some data changed to protect the
confidentiality of the project. However, the material presented is a valid
representation of the Product Performance Profile study issues.
There are 4 steps to developing attributes
for evaluating VE proposal candidates. They are, Selecting, Ranking,
Scaling and Displaying Attributes.
Its important that the Project Sponsors, or
stake holders have an active part in selecting, defining and evaluating
attributes. The attributes and their definitions selected in our case
study are shown in Figure 1.
Note that after much discussion, 9
attributes were selected and defined for the next step. The reason for
selection 9 when the process calls for a limit of 8 attributes is that in
performing "Paired Comparison," one of the attributes will
receive a score of "zero’ and will be dropped as from the list of
The "Paired Comparison" process
(Ref. FIGURE 2) is used to determine the relative importance of the
selected attributes and assign a percentage (weight) value to the
In the Paired Comparison process,
attributes are evaluated in pairs. The question asked is, "Given a
snapshot of the current condition of the project, which is more important,
Unit Cost (A), or Reliability / Durability / quality (B) ?" Another
way of asking the question is; " If you are given a sum of money to
invest in improving only one of the two attributes, would you use the
funds to improve Unit Cost (A), or Reliability / Durability (B)?" The
participants selected Unit Cost (A). The next question asked was, "Is
the degree of importance separating (A) from (B), a high difference (3),
medium difference (2) or low difference (1). The participants agreed that
there was a high difference of importance between (A) and (B). This is
indicated by scoring A3 to the first square. After comparing Unit Cost to
the remaining attributes, the second attribute (B) is compared to the
remaining attributes, and so on, until the paired comparison process is
The attribute score is determined by adding
the numeric value of the attributes (letters). Note that "Recycability"
received a "zero" and was dropped. The score is then converted
to percentage representing the relative numeric value, or weight of the
attributes. Converting to percentage standardizes the assigning of numeric
values to the attributes.
The next step is to determining the range
of acceptability, or degree of goodness for each attribute, as shown in
FIGURE 3. Quantitative scales should be used wherever practicable.
However, qualitative scales are acceptable if clearly defined and
understood by the participants and the VE Team.
Note that "Packaging" and
"Ease of Installation" are not scaled quantitatively. It is
important to establish the lowest point of acceptability of each
attribute, represented by the values under column 1. This value represents
the lowest acceptable limit, or floor of the attribute. Any attribute that
falls below the floor value causes the entire product to be unacceptable,
regardless of the relative importance of that attribute. By selecting two
additional points for each attribute, the attribute scale can be filled in
Attributes are displayed in the form of a
star, or spider diagram. Since each attributed is divided into 10
increments of goodness, and the total value of rated attributes will
always equal 100, the total possible Product Performance Profile score
will always be 1,000 points. FIGURE 4 shows a score of 275 out of a
possible 1,000, for the project "Base Case" as determined by the
pre-event participants. To construct the star diagram, the participants
agree on each attribute score of the base case, from 1 to 10. That score
is multiplied by the weight of the attribute and displayed in the row
labeled "Base Model" and the star is configured accordingly. A
target score is then established as a project goal. The VE Team effort to
achieving the target score encourages trading off lower valued attributes
for higher value attributes, provided that no attribute falls below the
minimum acceptable limit.
A study of some 150 projects shows that a
base case of around 500 points or below indicated the need for value
improvement. The target range for a project should be between 650 to 750.
Although the top score of 1,000 points is mathematically possible, trading
low valued attributes for higher valued attributes makes exceeding 800
points highly improbable. If the base case scores over 500 points the
score could be an indication that; (a) there is little opportunity for
improvement, or (b) the participants were overly optimistic in scoring the
base case, or (c) the wrong attributes were selected for the project.
FIGURE 4 indicates that the base case score
is 275 against a target of 650 points. Note that although the other
attributes are within acceptable limits, the "Unit Cost"
attribute is higher then the minimum acceptable cost and price (indicated
by the arrow) necessary to enter the market.
A comparison of the base case to the
company’s major competitor is shown in FIGURE 5. This figure shows that
the assumed cost of the competitors unit is well within acceptable limits.
However, two of his attributes, "Noise" and
"Packaging," are below the lowest acceptable level.
At this point, neither the manufacturer or
his competitor have market acceptable products because each have
attributes that scored below the minimum acceptable limit. Note also that
even though the attributes in question scored below one, the scoring will
use "(1)" as the multiplier times the attribute weight to
determine the attributes score.
FIGURE 6 shows the result of the VE
Workshop. The recommended VE team proposal exceeded their Product
Performance Profile goal by 101 points, earning 751 out of a possible
1,000 points. The VE Task Team considered another proposal scenario having
a lower product cost, but the overall score was shy of the 650 point
target. Although the recommended proposal did not have the lowest product
cost, it represented the best proposal based on the Product Performance
The Product Performance Profile display is
a good source of support for presenting the VE Task Team proposal. Since
key ERB members were party to selecting, ranking and scaling the
attributes, there was little problem in obtaining necessary approval for
the recommended proposal and the development and implementation funds
necessary to achieve the proposed design. Some ERB members requested
comparing three conditions; the base case, the competitors entry and the
proposed design. If more then two conditions are displayed at the same
time, it is best to use a "spider web" display rather then the
"star’ configuration, as shown in FIGURE 7.
Using the spider web configuration offers a
clearer distinction between multiple conditions being compared (Ref.
FIGURE 7). Note that the proposed design has a higher physical weight
(lower score) then the base case or the competitors product, but the
weight is within acceptable limits (Ref. Attribute D). Also, a comparison
between the proposed design and the competitive product shows a positive
314 point difference in attribute scores.
With a better understanding of the project
goals and issues to be resolved, the pre-event participants discuss and
list "sacred cows," that are standing in the way of achieving
the project objectives. Sacred cows, or roadblocks are defined as
"a non-functional constraint, perceived restriction or
The key word in the definition is
"perception." If the participant believes that a restriction
exists, regardless of the contrary, the participants actions and decisions
will treat and reflect that restriction as fact. A second important term
is "non-functional." Sacred cows or roadblocks do not directly
relate to functional requirements. Most sacred cows emerge from tradition,
policies or regulations.
By discussing and listing the sacred cows,
they can be confirmed or discarded by the project authorities. Those
sacred cows that remain are set aside to be re-evaluated against solution
options. If a sacred cow is in conflict with a proposed solution the team
determines the origin of the sacred cow and studies ways of overcoming
that concern or constraint.
Sacred cows express a constraint intended
to prevent the recurrence of an unwanted condition, but that condition is
rarely described. To determine the origin of the sacred cow ask,
"What problem or unwanted condition will be avoided by complying with
the constraint?" Knowing and understanding the concerns, then
contemplate: "Is there a better way?"
Some examples of sacred cows randomly
selected from a variety of VM Studies are as follows:
"Contracts will always be
awarded to the lowest bidder" (I)
"Stainless steel is the only
acceptable material" (I)(E)
"Products must be sized to fit
standard shipping containers" (I)
"Printed circuit boards can
only be purchased from our sister division"(I)
"It is better to please the
boss then satisfy the customers"(I)
"Butt weld joints are
"The product must meet all
environmental specifications" (E)
(I) refers to an internal sacred cow, (E)
external sacred cows. Most sacred cow lists will show that the majority of
constraints are internally generated, rather then imposed by external
As this point in the Pre-Event process the
participants should form an idea of the number of teams and the
disciplines needed in the teams to resolve the project issues. VM teams
are interdisciplinary. Why an Interdisciplinary team? Many years ago, an
analyst facilitated a Value Engineering study in the chemical industry.
The team consisted of eight chemical engineers. Considering the make-up of
the team, it shouldn’t have been too surprising to learn that all of the
problem resolutions considered were chemical solutions. The reason most
teams are made up of like-disciplined people is because common interests
work well together. Team members can communicate with each other, they can
objectively and professionally gauge other team members’ contributions.
However, homogeneous teams lack a sympathetic concern for the impact their
decisions have on other areas in the organization. Unfortunately,
homogeneous or single-disciplined teams often create more problems by
their resolutions than they solve.
Three questions govern which disciplines
should be represented on the team. These are:
- Who owns the problem?
- Who is responsible for the resolution of
- Who will be impacted by the resolution?
Answering the first question (Who owns
the problem?), the person or unit most affected by the problem should
be represented on the team. This is to ensure that in addressing the
problem owner’s or stake holder’s problem the focus is on the correct
problem, not its symptoms.
Answering the second question (Who is
responsible for the resolution of the problem?) is easier if the
problem to be resolved is correctly defined. That problem definition will
suggest which disciplines should be involved in resolving the problem.
Those disciplines will also be responsible for implementing the proposed
resolutions. If the problem is defined as management driven, then managers
should serve on the team. If the problem is technical, then the technical
staff should be represented.
The third question (Who will be impacted
by the resolution?) is important because it further ensures that the
problem, not its symptoms is being addressed. Including representatives
for areas potentially affected by the proposed resolutions will also
ensure that in solving the assigned problem the solution doesn’t result
in creating greater problems in other areas.
Referring to our widget example, a two
sub-team workshop is a consideration. One team would address cost
reduction opportunities, as the second team focuses on improving value
adding attributes. In the workshop environment the teams would conduct
their studies concurrently, coming together as a single team at the
planning phase of the Job Plan to form joint proposals.
Some disciplines considered in forming the
teams would include; Marketing, Manufacturing Engineering, Design
Engineering (electrical, mechanical, systems, etc.), Industrial Design,
Cost Estimating, Quality, Procurement, Finance (or Cost Accounting). Also,
dependent on the direction and structure of the workshop, the team make-up
would include a customer or distributor representative, suppliers and a
"wild card." A "wild card" is an individual who is
competent in discussing the project issues, but does not have a vested
interest in the study and is therefor considered unbiased. Wildcards are
selected from other projects, divisions, companies or to break through
paradigm constraints, different industries.
Team size should range from five to eight
participants. This applies to the "core" or full time team.
Other services can be added to the team, on an as needed or part time
basis, but the core team should be small, relevant and focused on the
project. The Steering System case study described above was conducted with
four teams, each responsible for a major product subsystem. The teams
networked periodically to insure that in perusing their sub-team goals,
one sub-team’s approach did not detrimentally effect the other team’s
With the project team(s) named, the team
participants are given information gathering assignments consisting of
specific and general information, by discipline, needed for the project
and the VM process. Team members will search their data resources to
gather and compile the information into a Project Data Bank. A review of
the available data is scheduled for the first morning of the VE Workshop.
The agenda outline that follows describes
the prevent topics discussed above and additional issues requiring
resolution prior to the start of the VE Task Team project.
Orientation and VE
Day 1, AM
* Project Overview, Project Briefing
+ Project briefing
+ Discuss the candidate project(s), issues, expectations
+ Identify specific goals
+ Resolve implementation timetable
+ Identify high cost - time drivers
+ Discuss market - business pressures
+ Identify and define customer / owner needs, wants
+ Resolve and form a Project Executive Review Board (ERB)
+ ERB’s role at and following the VE Workshop
Day 1 PM
* Overview / Orientation, a JJK briefing to Management /
+ Present and discuss VE concepts and the
advantages of a workshop
o Review applicable case study examples
o The VE Methodology and plan
o Daily activities and benchmark goals of the workshop
+ Resolve the 3 project issue questions:
o What is the problem we are here to resolve?
o Why do you consider this a problem?
o Why do you believe a solution is necessary?
+ Define (confirm) measurable goals
Day 2, AM
* Team briefing, Discuss the VE Workshop format and problem
+ Select and define those attributes that
determine the success of the project
+ Rank the attributes for trade-off and proposal evaluation
+ Scale the attributes
+ Configure the base case in PPP format
+ Identify "sacred cows" (paradigms)
+ Create a shopping list of information needed for the VE Workshop
Day 2, PM
* VE Project Planning. Define the project(s) and participating
+ Resolve what is included and excluded
in the scope of the project(s)
+ Confirm number of teams required
+ Confirm disciplines needed for the teams
+ Identify team leaders
+ Confirm Staff support services for the teams
+ Using key suppliers
+ Identify team participants and invite to the workshop
* Logistics and event planning meeting
+ Confirm workshop date and location
+ Arrange for text notes and other study guides
+ Resolve facility location, room layout, equipment and supplies
+ Assign pre-event team reading assignments
+ Create Action Plan, Pre-workshop Assignments
* Closing comments
The Value Engineering discipline and Job
Plan created by Lawrence D. Miles has stood the test of time. VE continues
to find new opportunities in diverse markets and cultures. As new
initiatives emerged, stake holders are finding that newly discovered
approaches such as "value improvement" and "team
building" are already proven VE process techniques.
"Information" is another VE criteria deserving of attention in
this technology accelerated business environment. However, VE is being
challenged to address more complex problems, while reducing the time to
resolve those problems. It is important that VE practitioners resist
pressures to abbreviate the job plan, and convince senior management on
the value of investing in the time to uncover and process information
prior to attempting to resolve those problem issues. Value Practitioners
should not attempt to shorten the problem solving process. They should
instead find the justification to expand the time necessary to gather and
evaluate all relevant project information before attempting to solve the
1. Marks, Peter, "Defining Great
Products", Design Insight, 1991.
2. Kaufman, J. Jerry, "Value
Management A Methodology, Not A Tool", Value World, Vol., 15
No. 1, 1992, p.13-17.
3. Kaufman, J. Jerry & Carter, Jimmie
L., "Evaluating Brainstorming Ideas," SAVE Proceedings 1994,
Vol. XIX, p. 186-194.
4. Kaufman, J. Jerry, (1985) Value
Engineering For The Practitioner, North Carolina State University,
the Author: Jerry
Kaufman, CVS, FSAVE, is President of J. J. Kaufman Associates, Inc.
He has an engineering degree from the Academy of Aeronautics and Johns
Hopkins University. As Corporate Director of Value Management for Cooper
Industries, Jerry developed and successfully implemented Value Engineering
in the corporate environment. His 25 years of progressive management
positions with the Martin Co., Honeywell, and Cooper span the industrial,
energy, process, service and aerospace industries. Jerry has written three
books and numerous papers and articles on Value Management. He is past
President of SAVE and past Chairman of the CVS (Certified Value
Specialist) Certification Board.