Technology Review
Value
Engineering
Revision: 11 July 2006
Author: Jack Caldwell
http://technology.infomine.com
Table of Contents
Presentation
and Implementation
Value Engineering
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.
Information Phase
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.
Function Analysis
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
verb-noun combination
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:
- The highest cost
activities. Value engineering is an expensive
exercise; it is best to concentrate the attention of the team on those
parts, aspects, or activities that will cost the most and where
improvements will yield the greatest possible cost reduction.
- Fulcrum Activities. These I
define as activities that seminally affect downstream or subsequent
activities. These are the
activities which, if done in different ways, have a significant impact on
the whole course of cleanup. For
example, a decision to treat mercury contaminated equipment by thermal
roasting or dipping it in an acid bath affects the way the equipment is
removed and prepared for treatment, and also how treated equipment and
treatment waste are disposed of.
- Politically
sensitive activities. As the name implies, these are
activities that make or break the project.
These activities have the highest public and regulator
visibility. The purpose of the VE
workshop may well be to find alternative ways of cleaning up a site that
are more acceptable to stakeholders. Cost reduction may not be a factor at
all. In such a case, it may be
vital to further value-engineer the highest profile issues, even though
the cost implications are minor.
Speculation
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.
Alternative Comparison
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.
Analysis
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.
Concept Development
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.
Presentation and Implementation
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.
Report
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
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:
- You will become the leader of
the group by virtue of the simple human desire to let somebody else take
the front and most vulnerable position; resist this, for your power as a
facilitator is great enough without letting human dynamics cloud your
fiduciary duty.
- You must protect the weakest
participant and find creative ways to bring them into the discussion; they
frequently have the best ideas, but are reticent to express them.
- A little strength and power
wielded over the dominant participant may be the only way to keep the
proceedings on an even keel, and to prevent dictatorship from being
established.
- Get everything that is said
on paper; this demands that you listen continually and seek out the
essence of what is being said; write it down and then interrupt the
proceedings to ask the participants to review and approve what you have
written down.
- Do not be afraid to
synthesize. i.e., bring in ideas and issues together, to arrange and
collate suggestions and issues, and to propose new ways yourself if the
idea come to mind.
- Be prepared to alter the
standard VE procedure; it works well most o f the time, but when it does
not, it is best replaced quickly with other group deliberation techniques
such as root cause analysis, roadmapping, and the compilation of
charts and lists.
Participants
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.