team decisions
Seven heads are better than one, but it takes a lot of care and nourishing to keep group dynamics on track.
By David G. Ullman
During product development many problems deal
with complex, strategic, and influential issues that require team resolution.
A poor decision on these problems may not be easily corrected later or
noticed in time to correct it. Poor results may have significant impact
on product quality, cost, and development time.
There is much evidence in most companies that the decision-making process
could be better. For example, decisions don't stick, so issues that earlier
seemed resolved are often revisited.
Team members don't buy into decisions. They may say they do, but then
pursue their own agendas.
Group decisions are made by edict, according to the loudest voice, or
in haste at the last minute.
There is little confidence in the resulting decisions, especially those
made early in the process—when information is uncertain.
The team fails to draw on collective expertise to reach the best decisions.
The decision-making process isn't reusable. There is no history of, or
justification for, previous decisions. Do any of these problems sound
familiar? They are the symptoms of poor decision making.
Team decision making is often complex and difficult to structure. It involves
solving problems that require the best use of an organization's intellectual
assets, which are stored in human minds, with each person bringing different
expertise, insight, and perspective.
Consider the following case study. BikeE Inc., a manufacturer of recumbent
bicycles in Corvallis, Ore., introduced a very successful product in 1998
and was trying to decide what to develop next. Recumbents are the low-slung
bicycles whose profile is intended to make more efficient use of human
pedaling. BikeE has built a reputation for turning out innovative models
priced to appeal to a large buying public.
Using
techniques to aid group decision making, a design team took a recumbent
bicycle off the beaten path.
The product management team's situation was fairly typical. The team
consisted of 10 people representing different functional areas, including
engineering, manufacturing, sales, and administration.
Some product concepts were proposed, but there had been no effort to reach
a shared vision of them. None of the concepts was well refined. Among
them were a mountain bike, a tandem, and a child's bike.
There were no clear criteria for selecting among the concepts. Everybody
was concerned about profit, price, and how a product might affect the
company's image, but none of those issues had been discussed or refined.
The team had limited time and funding.
In short, this team, like most, was faced with uncertainty, limited resources,
and the desire to make the best choice with buy-in by everyone in the
group.
The route they chose led to the development of a recumbent bike designed
specifically for off-road use.
If the team had made a poor choice, they might have ended up making a
product that did not sell well, was overpriced, or was late to market.
Teams often don't know how well they have done until long after the decision
is made, so it is imperative that they make the best decisions possible,
the first time.
It is surprising that so little emphasis is placed on decision making
in a typical engineer's training. Making decisions is a critical activity
in product development. Whenever a concept is chosen, a new feature is
added to a part, or a vendor selected, a decision has been made.
Before the mid-1980s, product development was focused on the end result.
In the 1990s, concern for the process resulted in standards like ISO 9000.
The focus is now moving toward how people interact, either face to face
or across distances, to make decisions.
Whenever one of many proposed alternatives is chosen, it becomes the focus
of time, money, and other resources. If developers later change their
minds, a majority of the intervening time is lost and expenditures are,
for the most part, unrecoverable. Decisions commit the decision-makers
and others to further effort. In fact, part of decision making is determining
how much commitment each alternative will require.
Given the importance of decisions, it is worthwhile to explore methods
that can help teams choose the best courses of action.
Developers are encouraged to generate more than one possible solution
to a design problem. Having to choose among many forces them to analyze
and compare.
A case in point comes from a dissertation, Thinking Methods and Procedures
in Mechanical Design, published at the Technical University of Munich
in 1991. Norbert Dylla, the author of the dissertation, described an experiment
involving six mechanical engineers. Each engineer worked independently
for about 10 hours on the same simple design problem: to mount a camera
on a wall. The problem was well specified with numerous criteria that
had to be met, such as angles for adjustment, locking capabilities, and
ease of mounting. The aggregate number of concepts considered by all the
subjects totaled 18, including various methods of adjusting, locking,
and mounting.
An independent group of engineers judged results by measuring how well
the final designs met the original criteria. The results showed a significant
relationship between the number of alternatives explored and the technical
quality of the chosen solution.
How do you encourage people to generate multiple alternatives? One manager
said that his engineers always had at least three alternatives. When asked
why, he responded that he would not approve a new idea unless at least
two other solutions for the problem were presented at the same time.
Experience suggests that effective team situations generate multiple alternatives
as the result of normal communications. This is especially true in a collaborative
environment, when team members have established an atmosphere of trust.
If multiple ideas are not generated in a team situation, it is likely
symptomatic of a rubber-stamp process where management does not encourage
and reward ideas.
Criteria are needed to measure the important features of alternatives.
If the criteria for a satisfactory solution are not defined at the beginning,
the only way to know you are done is to run out of time.
At the same time, criteria need room to evolve as understanding of the
problem develops. Early criteria may be uncertain and can be refined only
as the project progresses. In balancing these two opposing views, awareness
and control of the evolution of criteria are what is important.
'Feature Creep'
If criteria are not documented, they will change during problem solving.
This is commonly called "feature creep." It can come from
business units such as marketing and sales, and can also come from within
a project. If criteria are not documented, they become unmanageable.
If criteria are not shared among the team members, each may be working
toward a different goal, while they all believe they are working in common.
The design activities of Norbert Dylla's six engineers were also
evaluated to find how much of the total problem-solving time each one
spent to understand and develop criteria. There was a strong correlation
between the percentage of time spent analyzing the criteria and the technical
quality of the result.
A similar study, although in a different field, suggests that the same
holds true for teams.
This study looked at 17 seven-person teams as they tried to solve open-ended
problems concerning claims of more than $50,000 in the insurance industry.
The researchers counted the number of times criteria were discussed during
each team's deliberations. Then two experts in the field judged
the effectiveness of each team's solution. The results, published
in Southern Communication Journal in September 1997, showed that effective
teams expended twice the effort establishing evaluation criteria as did
ineffective teams.
Most problems are caused by information that is uncertain. It is important
to be aware of uncertainties and control them during decision-making.
Last year, at the beginning of a 21Ú2-year project, a team of 20
people in a large high-tech firm needed to select a technology for a new
ink jet delivery system. The team's goal was to select one technology
to develop in a typically uncertain research and development environment.
They faced uncertainty because they had neither time nor money to refine
all the alternatives, and some of their information was qualitative.
Inconsistencies arose because team members represented different functions
within the company. Their evaluations of the alternatives varied and,
in some cases, conflicted.
The data were constantly evolving. Throughout the deliberations new information
was introduced, at times without warning and at other times purposefully
collected.
The team needed to choose the best alternative with the least sensitivity
to these uncertainties, and to get all its members to buy into the final
decision.
The team members came up with five alternatives to study and developed
15 criteria, including time to first prototype, system cost, refill time,
and system reliability, against which to judge each idea.
Using Belief Maps
This team used belief maps to help manage the uncertainty, inconsistency,
and evolution of their work. The belief map is a method of graphically
representing relative levels of knowledge and confidence.
It is a plot whose horizontal axis represents the evaluator's knowledge
of the alternative's feature measured by the criterion. The vertical represents
confidence in the concept's ability to meet that criterion.
This team's work is proprietary and cannot be discussed in detail. But
to illustrate, consider a hypothetical example. For instance, one of the
alternatives a team develops is called "dropper" and a criterion
on a team's list is "ease of manufacture." Carlos may admit
little firsthand knowledge of manufacturing the dropper by plotting a
point left of center on the map. He believes the concept might be about
average in manufacturing ease, and so places a point halfway up the grid.
Liza, with more knowledge and higher confidence in manufacturing efficiency
of the dropper, will plot a point closer to the upper right-hand corner.
Five other members of the team will find their own points.
A
belief map graphically depicts differing levels of knowledge and confidence;
it is intended to guide discussion toward consensus.
Belief maps make it easy to visualize uncertainty (that is, lack of knowledge)
and lack of consensus. More on the use of belief maps is available in
the book 12 Steps to Robust Decisions, written by the author of this article
and published by Trafford Publishing of Victoria, British Columbia.
Belief maps even the evaluation playing field and provide a forum for
sharing and combining information. No one has a louder voice than anyone
else and the knowledge of the whole team can be brought to bear on the
evalution.
For most nonroutine design problems no one is an expert in all the areas
that need evaluation. Although some people have more knowledge than others
about certain factors, many on the team have knowledge important to the
decision. Thus, it is critical to combine the expertise of many on the
team to the best advantage. There are mathematics that do this combining.
These are doable by hand from the belief maps, but not easily, and there
is computer software, Accord, which does them automatically. Accord is
available through the author's company.
The use of belief maps helped move the team, in the words of the team
leader, "from relying on a few experts who have all the knowledge
to a team, many of whom have valuable knowledge."
Use of the belief maps greatly improved communication within the BikeE
team. For the first time, they clearly articulated the criteria and the
alternatives. The discussions were facilitated by the belief maps as they
compared and contrasted their evaluations.
They reached the decision that they should design and market a recumbent
mountain bike. The product proved to be innovative and opened new markets
for BikeE.
The ink jet team chose a system that is now in development. The team manager
is convinced that the company can bring the product to market six months
earlier than originally planned.
David G. Ullman, an ASME Fellow, is president of Robust Decisions Inc. in Corvallis, Ore., a company that provides software, services, and consulting for product development. He is also a founder of BikeE Inc.