The Preparation and Operation of a Workshop
Insuring VE Success

J. Jerry Kaufman
J. J. Kaufman Associates, Inc.
Houston, Texas

CONTENTS:

ABSTRACT

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.

INTRODUCTION

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 issues.

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 a product.

EXPANDING 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 activity.

Table 1: The Processing of Information

The 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.

Defining the 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 members.

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.

Some Examples

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%.

THREE QUESTIONS

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 questions are:

"What is the problem (or opportunity) we are about to resolve?"

"Why do you believe this is a problem?"

"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 profit."

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 product line.

"Why do you believe this is a problem?"

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.

GOAL AND OBJECTIVES

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 Board.

"Optimize," "maximize" 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 characteristics.

PRODUCT PERFORMANCE PROFILE

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.

A Case Study

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.

Selecting 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 active attributes.

Ranking Attributes

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 attributes.

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 complete.

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.

Scaling 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 by interpolation.

Displaying Attributes

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 Profile score.

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.

SACRED COWS

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 paradigm."

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 unacceptable" (I)(E)

"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 sources.

THE TEAM

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.

Selecting Team Participants

Three questions govern which disciplines should be represented on the team. These are:

• Who owns the problem?
• Who is responsible for the resolution of the problem?
• 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 proposals.

PROJECT INFORMATION

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.

Pre-Event Meeting Agenda

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 Planning Meeting

PROPOSED OUTLINE

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 / Planning Staff

+ 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 definition

+ 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 disciplines

+ 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

 

CONCLUSION

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 problem.

REFERENCES

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, Raleigh, NC.

About 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.

This site last updated 06/22/10
Submit comments to webmaster@ideationtriz.com
© 2006-2010 Ideation International Inc.