Revision: 11 July 2006
Author: Jack Caldwell
Table of Contents
Value Engineering (VE) is a means of evaluating the function, cost, and objectives of a design or construction project with the purpose of improving the value (function) of the design of its components, or reducing the project cost.
Here is a personal perspective of VE workshops culled from a report I wrote for a confidential client. There is a lot more on the web.
A member of the design team usually makes a presentation to explain the main concepts of the design, including project objectives, design constraints, drawings, specifications, and special conditions that are integral to the project. The estimated cost and contingency cost of the project are also described.
A good rule is that those who present the information should not take part in the VE workshop. They are usually too close to the project to be objective, and too defensive about what they have done to easily entertain new ideas that the essence of successful VE workshop. If members of the design team are included in the VE workshop, they should be a small minority of the group; they should seek to enter the spirit of free enquiry; and they should at all costs avoid being defensive.
I had difficulty facilitating a VE session when the chief engineer of the design group insisted on presenting all the information and being part of the VE study. He insisted on his right to make management decisions in the VE workshop and to control the course of discussion. A quiet talk in the corridor outside the meeting room was necessary to persuade him to relinquish control and in fact withdraw from the VE workshop. The VE team came to a conclusion diametrically opposed to the chief engineer’s desires; but he was prudent enough to implement their recommendation and the success of the design played a significant role in his subsequent career success.
In the function analysis phase:
· major project components are identified
· their functions are determined
· estimated cost of each component is assigned
A Function Analysis System Technique (FAST) diagram is prepared to help team members visualize the need for and role of each major component. In general, components are listed in functional order proceeding from what the design will do, on the left hand side of the diagram, to how objectives will be met, on the right hand side of the diagram.
Project components that are found to make little or no difference to overall project objectives will become subjects for further investigation in the subsequent VE phases. Similarly, project components with a high cost are also subjects for subsequent VE evaluation.
In addition to a FAST diagram, the VE team may decide to compile a project flow chart. This may show in chronological sequence the steps or activities that are involved in executing the project. Alternatively, I have had great success compiling fishbone diagrams. These diagrams are an attempt to list all the activities that are involved in or contribute to specific design components, or end results. The fishbone may, in additional, list alternatives for each activity.
A Typical Fishbone Diagram
Some techniques common to the compilation of FAST diagrams, project flow charts, and fishbone diagrams are:
Use post-it notes
They are easy to rearrange as ideas develop and different relationships and sequences are identified.
Describe each activity with a
Examples are excavate soil or treat waste. Use of a verb focuses attention on doing something and precludes fuzzy wishes and objectives becoming activities. Use of a noun focuses attention on an object, a physical reality, on the facility or component that is to be changed or affected by the action of the verb.
When the FAST diagram or other activity/relationship interlinking charts are complete, the VE team must decide which activities or functions they will consider in greater detail.
Generally it is not possible to take all activities or functions through all phases of value engineering. Only the key ones may or should be considered. For example, in the situation in this figure, you choose to VE only seats and space as a way to enhance comfort.
Criteria for selecting activities as key and hence subjecting them to continued value engineering scrutiny include:
During the speculation phase, the VE team considers each design component and suggests alternative means of accomplishing the function of the component. In this phase, team members are not allowed to criticize suggestions for alternative design components or approaches. This promotes creative thinking in the group.
Brainstorming involves the free flow of ideas. The facilitator is responsible for writing down each and every idea that is suggested. Some VE teams get going at this point and spontaneously generate long lists of ideas. Some VE teams are more conservative and slow to generate ideas. In order to elicit ideas, I, as a facilitator, have asked each person in turn to suggest at least one idea. This first, forced statement of ideas usually get things going; but if it does not, then go around the table two or three times, as long as ideas are still being generated.
Once a list of ideas or alternatives of acceptable length has been generated, the VE team sits back and, through common deliberation, tries to reduce the number of alternatives for further VE evaluation to about four or six.
I find that fewer than four ideas is restrictive, but seven or more takes too long for general patience, and are most often repetitive. Reduction to four to six alternatives may be done either by eliminating the more outlandish or obviously impractical ideas or by combining overlapping alternatives into more encompassing alternatives.
Remember: this is a serious institutional attempt to find new and better ways to do something. The silly idea may contain the germ of a new, better approach or detail. I like to carry forward at least one alternative that is deviant or radical. That way we reduce the danger of popular prejudice squashing a good idea before it has had time to germinate.
To compare alternatives, we must define comparison criteria. I like to identify comparison criteria in the same way as we identify alternatives: by brainstorming. Initially the facilitator goes around the room asking each person in turn to suggest a criterion that may be used to compare the alternatives. Most often this gets the team going and a long list is generated by free flow of ideas. If not, the facilitator keeps going around the room, soliciting criteria. The final list is once again reduced to four to six criteria by eliminating and/or combining.
A detailed definition must be compiled for each criterion that is adopted. The definition is a good place to include distinct ideas that are not adopted as separate criteria. Compiling criteria definitions is a valuable opportunity to promote discussion and exchange ideas. It is vital than all VE team members agree on definitions, otherwise confusion and disagreement will continue to plague subsequent deliberations.
The criteria are next weighted. This is one of the most entertaining and productive times of the VE workshop. Weighting involves comparing one criterion to each successive criterion. To illustrate the process: The first criterion is compared to the second criterion. Comparison is done by asking each VE team member to assign a preference score to either the first or second criterion.
The facilitator asks each team member for a preferred comparison criterion: cost vs. long-term effectiveness. Team members assign a score to their preference. The scale goes from 1 for “no preference” to 5 for “overwhelming preference”. Once all the votes are recorded, the facilitator invites those in the minority or whose votes differ most from the average to explain their viewpoint.
The discussion that ensues should be encouraged, for it focuses exchange of idea and perspectives, and frequently serves to efficiently disseminate information and perspectives. Team members may change their votes at any time during deliberations. It is up to the facilitator to bring closure to the discussion and prevent the discussion from drifting.
Next the first criterion is compared to the third criterion and the voting and deliberation process is repeated. This continues with comparison of the first and the fourth criterion, the second to the third criterion, etc., throughout the list. Scores for each criterion are totaled and weights are assigned to the criteria.
As a facilitator I have identified and weighted criteria both before and after identification of alternatives. I believe that it is better to establish criteria before identification of alternatives. If alternatives are identified first, there is an inevitable tension during the process of establishing the evaluation criteria, to create bias and consciously or unconsciously support preferences among the alternatives.
Analyzing alternatives involves comparing them to the criteria. The facilitator asks each team participant in turn to numerically evaluate each alternative against a specific criterion. Scores may vary from 1 to 5. A score of 1 indicates that the participant considers the alternative is in poor compliance with the criterion, or is a poor way to meet the objectives inherent in the criterion. Conversely a score of 5 indicates that the alternative is a very good way to comply with or meet the objectives of the criterion.
The facilitator lists all team participants’ scores for a specific alternative. Again, those in the minority or whose scores differ most from the average are asked to explain their scores. The discussion that ensues should be encouraged, for it will illuminate and disseminate aspects or issues not generally considered. Team members are free to change scores at any time during the discussion. When discussion is closed, the average score is computed and entered into the table. It is multiplied by the criterion weighting. The final score for each alternative is the weighted sum of the average scores.
Once the alternatives are scored and ranked, a sanity check must be made. The best way to do this is to let a team member present advantages and disadvantages of each alternative. When I am the facilitator, I ask each team member to give me one advantage and one disadvantage. I write this on the flipchart and let discussion ensue. At the end of the sanity check, the team considers whether the alternative rankings from numerical comparisons should be changed.
During the concept development phase, the concept selected by the VE team is organized and refined before presentation to the owner. Sketches may be prepared or a narrative report compiled. Cost estimates may be refined.
Concept development may require as little as four hours or as much as three weeks. A presentation more than a few days after the value engineering workshop loses the punch of the new, and so the shorter the concept development time, the better. If more time is needed, then it is not concept development but alternative design evaluation, which should follow rather than precede a formal presentation.
In the presentation/implementation phase, VE recommendations are presented to the client, owner, or project manager who is sponsoring the project. The project manager decides whether the VE recommendations should be incorporated into remedial action.
I prefer a presentation on the afternoon of the final day of the VE workshop. I like to conclude deliberations and discussion at about 11 a.m. and through a working lunch arrange and do a dry run of a presentation.
The presentation should be set for about 3 pm and last no longer than one hour. The presentation should not be made by the facilitator. One or more team participants should make the presentation. Who should present always seems to be obvious.
Depending on the budget, topic, and significance of the VE workshop, a formal report may be prepared. Generally the most cost-effective method is to have the flipcharts photo-reproduced, copied, collated, and distributed. This provides a full record of deliberations, scores, recommendations, etc. If budget is available, the flipcharts may be typed and the sketches turned in to graphics. Sometimes a formal report is written. This should be ready for distribution no more than three weeks after the VE workshop.
The facilitator should be chosen with care. Professional VE facilitator may be used; they need have no specific knowledge of the project or even of the technologies involved. In such a case their role is simply to act as a neutral presence and to make certain that the workshop is conducted in accordance with standard VE procedures.
One o f the most productive VE workshops I attended was facilitated by a profession facilitator who knew the project, its setting, and politics, but was not an engineer. His skill lay in balancing the strong personalities of those in the VE team, making sure all sides of the argument were heard and recorded, and that we did not spend too much time on any one phase of the VE agenda.
I have heard of VE workshops where the facilitator was the boss (the project manager, the chief design engineer, or the client). Those who told me of this also said that the sessions were a flop. This is as one would expect. The very presence of the boss will inhibit the free flow of ideas that is at the heart of a successful VE workshop. Participants will tailor their ideas and discussion to the agenda of the boss, and inevitably office or project politics and territoriality will interfere with neutral evaluation of alternatives. The boss VE facilitator will guide the discussion to confirm and praise, not criticize or overturn current project approaches and details.
I have facilitated a number of VE workshops. In some I knew nothing of the project until the VE workshop began. In other I have been familiar with the project and the specific technical details of the project activities or components being evaluated. I have never been the boss of the project for which the VE was done. In most of the VE workshops I have facilitated, most of the team were people I would describe as my peers.
Some VE projects have included my clients (in the sense that they are paying me and all project bills). Only once was this an impediment to progress, and that was swiftly dealt with by reminding the client that they were paying to elicit new ideas, and at any rate had a right of absolute veto over any recommendation made by the VE team.
I would like to believe that in at least two of the VE workshops I facilitated, my intimate knowledge of the project and the technology being evaluate contributed to the success of the VE workshops. When the conversation flagged or took unproductive turns, I was able to liven things up or to provoke new lines of inquiry by raising issues or suggesting alternatives that had escaped the VE participants. This confirms the value of a facilitator who knows the project, or is an expert in the primary technologies involved in the project.
Sometimes a project participant is suited by temperament to the task of facilitator, and sometimes the personal interest is a benefit. The person sponsoring the workshop must decide on the basis of their knowledge of the project, its technologies, and the potential participants’ personalities whether to use a project person as facilitator, or to select a knowledgeable but disinterested facilitator, or to bring in a professional facilitator who may know nothing of the technologies, the people, or the project.
Observations from facilitating VE workshops that might help if you are asked to do the same:
Never let the number of participants fall below five. Fewer than that and there is not enough energy in the room to keep things moving. Four people quickly tire of each other; boredom sets in, or worse, all agree and no new ideas are generated by the tensions that seem to be inherent in larger groups.
Never let the number of participants rise above twelve. I read somewhere that twelve is the largest group where one-to-one communication is possible and where the camaraderie and spirit that makes for a successful team may develop. I have heard of VE sessions as large as thirty. They reportedly failed to achieve anything.
I prefer a group of eight. There should be a balance of senior and mid-level experience. The majority should be well versed in the technology being examined. Good Luck.