《高效的项目和团队》的内容介绍
《高效的项目和团队》的内容介绍
Productive Projects and Teams是一本好书。 许多其中许多关于管理和沟通的精辟言论让我大有相见很晚之感。其实不仅是软件的开发项目，任何项目，甚至任何行业的管理，都首先是对人的管理，然后才是对事物的管理，所以设身处地的为别人着想，用鼓励来代替批评，用相互学习来取消互相排挤，在失败中学习，在前进中自醒，则无往而不胜。鉴于原书是英文的，我打算利用业余时间把它翻译成中文，一来方便后学者，二来以此提高自己的英文水平。我将在这里随时提供翻译的最新动态。
下面是原文文本
PART I
MANAGING THE HUMAN
RESOURCE
Most of us as managers are prone to one particular failing: a
tendency to manage people as though they were modular components.
It's obvious enough where this tendency comes from.
Consider the preparation we had for the task of management: We
were judged to be good management material because we performed
well as doers, as technicians and developers. That often involved
organizing our resources into modular pieces, such as software routines,
circuits, or other units of work. The modules we constructed
were made to exhibit a black-box characteristic, so that their internal
idiosyncrasies could be safely ignored. They were designed to be
used with a standard interface.
After years of reliance on these modular methods, small wonder
that as newly promoted managers, we try to manage our human
resources the same way. Unfortunately, it doesn't work very well.
In Part I, we begin to investigate a very different way of
thinking about and managing people. That way involves specific
accommodation to the very nonmodular character of the human
resource.
Chapter 1
SOMEWHERE TODAY,
A PROJECT IS FAILING
Since the days when computers first came into common use,
there must have been tens of thousands of accounts receivable programs
written. There are probably a dozen or more accounts receivable
projects underway as you read these words. And somewhere
today, one of them is failing.
Imagine that! A project requiring no real technical innovation
is going down the tubes. Accounts receivable is a wheel that's been
reinvented so often that many veteran developers could stumble
through such projects with their eyes closed. Yet these efforts
sometimes still manage to fail.
Suppose that at the end of one of these debacles, you were
called upon to perform an autopsy. (It would never happen, of
course; there is an inviolable industry standard that prohibits examining
our failures.) Suppose, before all the participants had scurried
off for cover, you got a chance to figure out what had gone wrong.
One thing you would not find is that the technology had sunk the
project. Safe to say, the state of the art has advanced sufficiently so
that accounts receivable systems are technically possible. Something
else must be the explanation.
Each year since 1977, we have conducted a survey of development
projects and their results. We've measured project size,
cost, defects, acceleration factors, and success or failure in meeting
schedules. We've now accumulated more than five hundred project
histories, all of them from real-world development efforts.
We observe that about fifteen percent of all projects studied
came to naught: They were canceled or aborted or "postponed" or
4 PEOPLEWARE
they delivered products that were never used. For bigger projects,
the odds are even worse. Fully twenty-five percent of projects that
lasted twenty-five work-years or more failed to complete. In the
early surveys, we discarded these failed data points and analyzed the
others. Since 1979, though, we've been contacting whoever is left
of the project staff to find out what went wrong. For the overwhelming
majority of the bankrupt projects we studied, there was
not a single technological issue to explain the failure,
The Name of the Game
The cause of failure most frequently cited by our survey participants
was "politics." But now observe that people tend to use this word
rather sloppily. Included under "politics" are such unrelated or
loosely related things as communication problems, staffing problems,
disenchantment with the boss or with the client, lack of motivation,
and high turnover. People often use the word politics to
describe any aspect of the work that is people-related, but the
English language provides a much more precise term for these
effects: They constitute the project's sociology. The truly political
problems are a tiny and pathological subset.
If you think of a problem as political in nature, you tend to be
fatalistic about it. You know you can stand up to technical challenges,
but honestly, who among us can feel confident in the realm
of politics? By noting the true nature of a problem as sociological
rather than political, you make it more tractable. Project and team
sociology may be a bit outside your field of expertise, but not
beyond your capabilities.
Whatever you name these people-related problems, they're
more likely to cause you trouble on your next assignment than all the
design, implementation, and methodology issues you'll have to deal
with. In fact, that idea is the underlying thesis of this whole book:
The major problems of our work are not so much
technological as sociological in nature.
Most managers are willing to concede the idea that they've got
more people worries than technical worries. But they seldom manage
that way. They manage as though technology were their principal
concern. They spend their time puzzling over the most convoluted
and most interesting puzzles that their people will have to
SOMEWHERE TODAY, A PROJECT IS FAILING 5
solve, almost as though they themselves were going to do the work
rather than manage it. They are forever on the lookout for a technical
whiz-bang that promises to automate away part of the work (see
Chapter 6, "Laetrile," for more on this effect). The most strongly
people-oriented aspects of their responsibility are often given the
lowest priority.
Part of this phenomenon is due to the upbringing of the average
manager. He or she was schooled in how the job is done, not
how the job is managed. It's a rare firm in which new managers
have done anything that specifically indicates an ability or an aptitude
for management. They've got little management experience and
no meaningful practice. So how do new managers succeed in convincing
themselves that they can safely spend most of their time
thinking technology and little or no time thinking about the people
side of the problem?
The High-Tech Illusion
Perhaps the answer is what we've come to think of as the High-
Tech Illusion: the widely held conviction among people who deal
with any aspect of new technology (as who of us does not?) that
they are in an intrinsically high-tech business. They are indulging in
the illusion whenever they find themselves explaining at a cocktail
party, say, that they are "in computers," or "in telecommunications,"
or "in electronic funds transfer." The implication is that they are part
of the high-tech world. Just between us, they usually aren't. The
researchers who made fundamental breakthroughs in those areas are
in a high-tech business. The rest of us are appliers of their work.
We use computers and other new technology components to develop
our products or to organize our affairs. Because we go about this
work in teams and projects and other tightly knit working groups,
we are mostly in the human communication business. Our successes
stem from good human interactions by all participants in the
effort, and our failures stem from poor human interactions.
The main reason we tend to focus on the technical rather than
the human side of the work is not because it's more crucial, but
because it's easier to do. Getting the new disk drive installed is positively
trivial compared to figuring out why Horace is in a blue funk
or why Susan is dissatisfied with the company after only a few
months. Human interactions are complicated and never very crisp
and clean in their effects, but they matter more than any other aspect
of the work.
6 PEQPLEWARE
If you find yourself concentrating on the technology rather
than the sociology, you're like the vaudeville character who loses
his keys on a dark street and looks for them on the adjacent street
because, as he explains, "The light is better there."
Chapter 2
MAKE A CHEESEBURGER,
SELL A CHEESEBURGER
Development is inherently different from production. But
managers of development and allied efforts often allow their thinking
to be shaped by a management philosophy derived entirely from
a production environment.
Imagine for the moment that you're the manager of the local
fast food franchise. It makes perfect sense for you to take any or all
of the following efficient production measures:
. Squeeze out error. Make the machine (the human machine)
run as smoothly as possible.
Take a hard line about people goofing off on the job.
. Treat workers as interchangeable pieces of the machine.
. Optimize the steady state. (Don't even think about how the
operation got up to speed, or what it would take to close it
down.)
. Standardize procedure. Do everything by the book.
. Eliminate experimentation—that's what the folks at headquarters
are paid for.
These would be reasonable approaches if you were in the fast food
business (or any production environment), but you're not. The
"make a cheeseburger, sell a cheeseburger" mentality can be fatal in
your development area. It can only serve to damp your people's
spirits and focus their attention away from the real problems at hand.
This style ofmanagementwill be directly atodds with the work.
8 PEOPLEWARE
To manage thinking workers effectively, you need to take
measures nearly opposite those listed above. Our proposed opposite
approaches are described in the following sections.
A Quota for Errors
For most thinking workers, making an occasional mistake is a natural
and healthy part of their work. But there can be an almost Biblical
association between error on the job and sin. This is an attitude
we need to take specific pains to change.
Speaking to a group of software managers, we introduced a
strategy for what we think of as iterative design. The idea is that
some designs are intrinsically defect-prone; they ought to be rejected,
not repaired. Such dead ends should be expected in the design
activity. The lost effort of the dead end is a small price to pay for a
clean, fresh start. To our surprise, many managers felt this would
pose an impossible political problem for their own bosses: "How
can we throw away a product that our company has paid to produce?"
They seemed to believe that they'd be better off salvaging
the defective version even though it might cost more in the long run.
Fostering an atmosphere that doesn't allow for error simply
makes people defensive. They don't try things that may turn out
badly. You encourage this defensiveness when you try to systematize
the process, when you impose rigid methodologies so that staff
members are not allowed to make any of the key strategic decisions
lest they make them incorrectly. The average level of technology
may be modestly improved by any steps you take to inhibit error.
The team sociology, however, can suffer grievously.
The opposite approach would be to encourage people to make
some errors. You do this by asking your folks on occasion what
dead-end roads they've been down, and by making sure they
understand that "none" is not the best answer. When people blow
it, they should be congratulated—that's part of what they're being
paid for.
Management: The Bozo Definition
Management is a complex enough thing to defy simple definition,
but that nuance was lost on one senior manager we encountered at a
professional society meeting in London. He summed up his entire
MAKE A CHEESEBURGER,SELL ACHEESEBURGER 9
view of the subject with this statement: "Management is kicking
ass." This equates to the view that managers provide all the thinking
and the people underneath them just carry out their bidding. Again,
that might be workable for cheeseburger production, but not for any
effort for which people do the work with their heads rather than their
hands. Everyone in such an environment has got to have the brain
in gear. You may be able to kick people to make them active, but
not to make them creative, inventive, and thoughtful.
Even if kicking people in the backside did boost their short-
term productivity, it might not be useful in the long run: There is
nothing more discouraging to any worker than the sense that his
own motivation is inadequate and has to be "supplemented" by that
of the boss.
The saddest thing about this management approach is that it's
almost always superfluous. You seldom need to take Draconian
measures to keep your people working; most of them love their
work. You may even have to take steps sometimes to make them
work less, and thus get more meaningful work done (more about
this idea in Chapter 3).
The People Store
In a production environment, it's convenient to think of people as
parts of the machine. When a part wears out, you get another. The
replacement part is interchangeable with the original. You order a
new one, more or less, by number.
Many development managers adopt the same* attitude. They go
to great lengths to convince themselves that no one is irreplaceable.
Because they fear that a key person will leave, they force themselves
to believe that there is no such thing as a key person. Isn't that the
essence of management, after all, to make sure that the work goes
on whether the individuals stay or not? They act as though there
were a magical People Store they could call up and say, "Send me a
new George Gardenhyer, but make him a little less uppity."
One of my clients brought a splendid employee into a
salary review and was just amazed that the fellow
wanted something other than money. He said that he
often had good ideas at home but that his slow dial-up
terminal was a real bother to use. Couldn't the company
install a new line into his house and buy him a
10 PEOPLEWARE
high-performance terminal? The company could. In
subsequent years, it even built and furnished a small
home office for the fellow. But my client is an unusual
case. I wonder what a less perceptive manager would
have done. Too many managers are threatened by anything
their workers do to assert their individuality.
—TRL
One example ofjust such a less perceptive manager was a boss
who showed extreme signs of being threatened by his people's
individuality: He had one very talented worker on the road for much
of the year visiting client sites and as a result living on expense
account. An analysis of the man's expense reports showed that his
expenditures on food were way out of line with those of other travelers.
He spent fifty percent more on food than the others did. In
an indignant public memo, the boss branded the worker a "food
criminal." Now, the worker's total expenditures weren't out of line;
whatever extra he spent on food, he saved on something else. The
man was not more expensive, he was just different.
The uniqueness of every worker is a continued annoyance to
the manager who has blindly adopted a management style from the
production world. The natural people manager, on the other hand,
realizes that uniqueness is what makes project chemistry vital and
effective. It's something to be cultivated.
A Project in Steady State Is Dead
Steady-state production thinking is particularly ill-suited to project
work. We tend to forget that a project's entire purpose in life is to
put itself out of business. The only steady state in the life of a project
is rigor mortis. Unless you're riding herd on a canceled or
about-to-be-canceled project, the entire focus of project management
ought to be the dynamics of the development effort. Yet the way we
assess people's value to a new project is often based on their steady-
state characteristics: how much code they can write or how much
documentation they can produce. We pay far too little attention to
how well each of them/ite into the effort as a whole.
/ was teaching an in-house design course some years
ago, when one of the upper managers buttonholed me to
request that I assess some of the people in the course
MAKE A CHEESEBURGER, SELL A CHEESEBURGER 11
(his project staff). He was particularly curious about
one woman. It was obvious he had his doubts about her:
"I don't quite see what she adds to a project^she's not a
great developer or tester or much of anything." With a
little investigation, I turned up this intriguing fact:
During her twelve years at the company, the woman in
question had never worked on a project that had been
anything other than a huge success. It wasn't obvious
what she was adding, but projects always succeeded
when she was around. After watching her in class for a
week and talking to some of her co-workers, I came to
the conclusion that she was a superb catalyst. Teams
naturally jelled better when she was there. She helped
people communicate with each other and get along.
Projects were more fun when she was part of them.
When I tried to explain this idea to the manager, I
struck out. He just didn't recognize the role of catalyst
as essential to a project.
-TDM
The catalyst is important because the project is always in a
state of flux. Someone who can help a project to jell is worth two
people who just do work.
We Haven't Got Time to Think About This Job,
Only to Do It
If you are charged with getting a task done, what proportion of your
time ought to be dedicated to actually doing the task? Not one hundred
percent. There ought to be some provision for brainstorming,
investigating new methods, figuring out how to avoid doing some
of the subtasks, reading, training, and just goofing off.
Looking back over our own years as managers, we've both
concluded that we were off-track on this subject. We spent far too
much of our time trying to get things done and not nearly enough
time asking the key question, "Ought this thing to be done at all?"
The steady-state cheeseburger mentality barely even pays lip service
to the idea of thinking on the job. Its every inclination is to push the
effort into one hundred percent do-mode. If an excuse is needed for
the lack of think-time, the excuse is always time pressure—as
though there were ever work to be done without time pressure.
The importance of a more considered approach goes up
sharply as the stakes increase. It's when the truly Herculean effort
is called for that we have to learn to do work less of the time and
think about the work more. The more heroic the effort required, the
more important it is that the team members learn to interact well and
enjoy it The project that has to be done by an impossible fixed date
is the very one that can't afford not to have frequent brainstorms and
even a project dinner or some such affair to help the individual participants
knitinto aneffective whole.
But all that is motherhood. Everybody knows that and acts
accordingly, right? Wrong. We are so single-mindedly oriented
toward Doing Something, Anything that we spend a scant five percent
ofour time on the combined activities ofplanning, investigating
new methods, training, reading books, estimating, budgeting,
scheduling, and allocating personnel. (The five percent figure comes
from an analysis of system development projects, but it seems to
apply more broadly than that, perhaps to the entire category of
salaried workers.)
The statistics about reading are particularly discouraging: The
average software developer, for example, doesn't own a single book
on the subject of his or her work, and hasn't ever read one. That
fact is horrifying for anyone concerned about the quality of work in
the field; for folks like us who write books, it is positively tragic.
Chapter 3
VIENNA WAITSFOR YOU
Some years ago I was swapping war stories with the
manager of a large project in southern California. He
began to refate the effect that his project and its crazy
hours had had on his staff. There were two divorces
that he could trace directly to the overtime his people
were putting in, and one of his worker's kids had gotten
into some kind of trouble with drugs, probably because
his father had been too busy for parenting during the
past year. Finally there had been the nervous breakdown
of the test team leader.
As he continued through these horrors, I began to
realize that in his own strange way, the man was bragging.
You might suspect that with another divorce or
two and a suicide, the project would have been a complete
success, at least in his eyes.
—TDM
For all the talk about "working smarter," there is a widespread
sense that what real-world management is all about is getting people
to work harder and longer, largely at the expense of their personal
lives. Managers are forever tooting their horns about the quantity of
overtime their people put in, and the tricks one can use to get even
more out of them.
14 PEOPCEWARE
Spanish Theory Management
Historians long ago formed an abstraction about different theories of
value: The Spanish Theory, for one, held that only a fixed amount
of value existed on earth, and therefore the path to the accumulation
of wealth was to learn to extract it more efficiently from the soil or
from people's backs. Then there was the English Theory that held
that value could be created through ingenuity and technology. So
the English had an Industrial Revolution, while the Spanish spun
their wheels trying to exploit the land and the Indians in the New
World. They moved huge quantities of gold across the ocean, and
all they got for their effort was enormous inflation (too much gold
money chasing too few usable goods).
The Spanish Theory of Value is alive and well among managers
everywhere. You see that whenever they talk about productivity.
Productivity ought to mean achieving more in an hour of
work, but all too often it has come to mean extracting more for an
hour of pay. There is a large difference. The Spanish Theory managers
dream of attaining new productivity levels through the simple
mechanism of unpaid overtime. They divide whatever work is done
in a week by forty hours, not by the eighty or ninety hours that the
worker actually put in.
That's not exactly productivity—it?s more like fraud—but
it's the state of the art for many American managers. They bully and
cajole their people into long hours. They impress upon them how
important the delivery date is (even though it may be totally arbitrary;
the world isn't going to stop just because a project completes a
month late). They trick them into accepting hopelessly tight schedules,
shame them into sacrificing any and all to meet the deadline,
and do anything to get them to work longer and harder.
And Now a Word from the Home Front
Although your staff may be exposed to the message "Work longer
and harder" while they're at the office, they're getting a very different
message at home. The message at home is, "Life is passing you
by. Your laundry is piling up in the closet, your babies are uncuddled,
your spouse is starting to look elsewhere. There is only one
VIENNA WAITS FOR YOU 15
time around on this merry-go-round called life, only one shot at the
brass ring. And if you use your life up on COBOL.,."
But you know when the truth is told,
That you can get what you want or you can just get old.
You're going to kick off before you even get halfway through.
When will you realize . . . Vienna waits for you?
—"The Stranger," Billy Joel
The Vienna that waits for you, in Billy Joel's phrase, is the
last stop on your personal itinerary. When you get there, it's all
over. If you think your project members never worry about such
weighty matters, think again. Your people are very aware of the one
short life that each person is allotted. And they know too well that
there has got to be something more important than the silly job
they're working on.
There AIn?i No .Such Thing as Overtime
Overtime for salaried workers is a figment of the naive manager's
imagination. Oh, there might be some benefit in a few extra hours
worked on Saturday to meet a Monday deadline, but that's almost
always followed by an equal period of compensatory "undertime"
while the workers catch up with their lives. Throughout the effort
there will be more or less an hour of undertime for every hour of
overtime. The trade-off might work to your advantage for the short
term, but for the long term it will cancel out
Slow down you crazy child,
And take the phone off the hook and disappear for a while.
It's all right. You can afford to lose a day or two.
When will you realize . . . Vienna waits for you?
Just as the unpaid overtime was largely invisible to the Spanish
Theory manager (who always counts the week as forty hours
regardless of how much time the people put in), so too is the undertime
invisible. You never see it on anybody's time sheet. It's time
spent on the phone or in bull sessions or just resting. Nobody can
16 PEOPLEWARE
really work much more than forty hours, at least not continually and
with the level of intensity required for creative work.
Overtime is like sprinting: It makes some sense for the last
hundred yards of the marathon for those with any energy left, but if
you start sprinting in the first mile, you're just wasting time. Trying
to get people to sprint too much can only result in loss of respect for
the manager. The best workers have been through it all before; they
know enough to keep silent and roll their eyes while the manager
raves on that the job has got to get done by April. Then they take
their compensatory undertime when they can, and end up putting in
forty hours of real work each week. The best workers react that
way; the others are workaholics.
Workaholics
Workaholics will put in uncompensated overtime. They'll work
extravagant hours, though perhaps with declining effectiveness. Put
them under enough pressure and they will go a long way toward
spoiling their personal lives. But only for a while. Sooner or later
the message comes through to even the most dedicated workaholic:
Slow down, you're doing fine,
You can't be everything you want to be before your time.
Although it's so romantic on the borderline tonight.
But when will you realize . . . Vienna waits for you?
Once that idea is digested, the worker is lost forever after to
the project. The realization that one has sacrificed a more important
value (family, love, home, youth) for a less important value (work)
is devastating. It makes the person who has unwittingly sacrificed
seek revenge. He doesn't go to the boss and explain calmly and
thoughtfully that things have to change in the future—he just quits,
another case of burnout. One way or the other, he's gone.
Workaholism is an illness, but not an illness like alcoholism
that affects only the unlucky few. Workaholism is more like the
common cold: Everyone has a bout of it now and then. Our purpose
in writing about it here is not so much to discuss its causes and
cures, but to address the simpler problem of how you, the manager,
ought to deal with your workaholics. If you exploit them to the hilt
in typical Spanish Theory fashion, you'll eventually lose them. No
matter how desperately you need them to put in all those hours, you
VIENNA WAITS FOR YOU 17
can't let them do so at the expense of their personal lives. The loss
of a good person isn't worth it. This point goes beyond the narrow
area of workaholism, into the much more complex subject of meaningful
productivity.
Productivity: Winning Battles and Losing Wars
Next time you hear someone talking about productivity, listen carefully
to hear if the speaker ever uses the word turnover. Chances
are that he or she will not. In years of hearing productivity discussed
and in hundreds of articles about it, we have never encountered
a single expert that had anything to say about the related subject
of turnover. But what sense can it possibly make to discuss one
without the other? Consider some of the things that organizations
typically do to improve productivity:
. pressure, people to put in more hours
. mechanize the process of product development
. compromise the quality of the product (more about this in
the next chapter)
. standardize procedures
Any of these measures can potentially make the work less enjoyable
and less satisfying. Hence, the process of improving productivity
risks worsening turnover. That doesn't say you can't improve productivity
without paying a turnover price. It only says you need to
take turnover into account whenever you set out to attain higher
productivity. Otherwise, you may achieve an "improvement" that is
more than offset by the loss of your key people.
Most organizations don't even keep statistics on turnover.
Virtually none can tell you what replacement of an experienced
worker costs. And whenever productivity is considered, it is done
as though turnover were nonexistent or cost-free. The Eagle project
at Data General is a case in point The project was a Spanish Theory
triumph: Workaholic project members put in endless unpaid overtime
hours to push productivity to unheard of levels. At the end of
the project, virtually the entire development staff quit What was the
cost of that? No one even figured it into the equation.
Productivity has to be defined as benefit divided by cost. The
benefit is observed dollar savings and revenue from the work per
18 PEOPLEWARE
formed, and cost is the total cost, including replacement of any
workers used up by the effort.
Reprise
During the past year, I did some consulting for a project
that was proceeding so smoothly that the project
manager knew she would deliver the product on schedule.
She was summoned in front of the management
committee and asked for a progress report. She said
she could guarantee that her product would be ready by
the deadline of March 1, exactly on time according to
the original estimate. The upper managers chewed over
that piece of unexpected good news and then called her
in again the next day. Since she was on time for March
1, they explained, the deadline had been moved up to
January 15.
—TRL
A schedule that the project could actually meet was of no value
to those Spanish Theory managers, because it didn't put the people
under pressure. Better to have a hopelessly impossible schedule to
extract more labor from the workers.
Chances are, you've known one or more Spanish Theory
managers during your career. It's all very well to smile at their
short-sightedness, but don't let yourself off the hook too easily.
Each of us has succumbed at one time or another to the short-term
tactic of putting people under pressure to get them to work harder.
In order to do mis, we have to ignore their decreased effectiveness
and the resultant turnover, but ignoring bad side effects is easy.
What's not so easy is keeping in mind an inconvenient truth like this
one:
People under time pressure don't work better;
they Just work faster.
In order to work faster, they may have to sacrifice the quality
of the product and their own job satisfaction.
Chapter 4
QUALITY—IF TIME PERMITS
Twentieth centurypsychological theory holds that man's character
is dominated by a small number of basic instincts: survival,
self-esteem, reproduction, territory, and so forth. These are built
directly into the brain's firmware. You can consider these instincts
intellectually without great passion (that's what you're doing now),
but when you feel them, there is always passion involved Even the
slightest challenge to one of these built-in values can be upsetting.
Whenever strong emotions are aroused, it's an indication that
one of the brain's instinctive values has been threatened. A novice
manager may believe that work can be completed without people's
emotions ever getting involved but if you have any experience at all
as a manager, you have learned the opposite. Our work gives us
plenty of opportunity to exercise the emotions.
Chances are, you can think of at least one incident when a
person's emotions did flare up as a direct result of something purely
work-related Consider that incident now and ask yourself (probably
for the nth time), Where did all the emotion come from? Without
knowing anything about your specific incident, we're willing to bet
that threatened self-esteem was a factor. There may be many and
varied causes of emotional reaction in one's personal life, but in the
workplace, the major arouser of emotions is threatened self-esteem.
We all tend to tie our self-esteem strongly to the quality of the
product we produce—not the quantity of product, but the quality,
(For some reason, there is little satisfaction in turning out huge
amounts of mediocre stuff, although that may be just what's
required for a given situation.) Any step you take that may jeopar
20 PEOPLEWARE
dize the quality of the product is likely to set the emotions of your
staff directly against you.
The Flight from Excellence
Managers jeopardize product quality by setting unreachable deadlines.
They don't think about their action in such terms; they think
rather that what they're doing is throwing down an interesting challenge
to their workers, something to help them strive for excellence.
Experienced (jaded) workers know otherwise. They know
that under the gun, their efforts will be overconstrained. There will
be no freedom to trade off resources to make on-time delivery possible.
They won't have the option of more people or reduced function.
The only thing to give on will be quality. Workers kept under
extreme time pressure will begin to sacrifice quality. They will push
problems under the rug to be dealt with later or foisted off onto the
product's end user. They will deliver products that are unstable and
not really complete. They will hate what they're doing, but what
other choice do they have?
The hard-nosed, real-world manager part of you has an
answer to all this: "Some of my folks would tinker forever with a
task, all in the name of 'Quality.' But the market doesn't give a
damn about that much quality—it's screaming for the product to be
delivered yesterday and will accept it even in a quick-and-dirty
state." In many cases, you may be right about the market, but the
decision to pressure people into delivering a product that doesn't
measure up to their own quality standards is almost always a mistake.
We managers tend to think of quality as just another attribute
of the product, something that may be supplied in varying degrees
according to the needs of the marketplace. It's like the chocolate
sauce you pour onto a homemade sundae: more for people who
want more, and less for people who want less.
The builders' view of quality, on the other hand, is very different.
Since their self-esteem is strongly tied to the quality of the
product, they tend to impose quality standards of their own. The
minimum that will satisfy them is more or less the best quality they
have achieved in the past. This is invariably a higher standard than
what the market requires and is willing to pay for.
QUALITY—IF TIME PERMITS 21
"The market doesn't give a damn about that much quality."
Read those words and weep, because they are almost always true.
People may talk in glowing terms about quality or complain bitterly
about its absence, but when it comes time to pay the price for quality,
their true values become apparent. On a software project, for
instance, you might be able to make the following kind of presentation
to your users: "We can extrapolate from empirical evidence that
the Mean Time Between Failures for this product is now approximately
1.2 hours. So if we deliver it to you today, on time, it will
have very poor stability. If we put in another three weeks, we can
forecast MTBF of approximately 2,000 hours, a rather respectable
result." Expect to see some Olympic-class hemming and hawing.
The users will explain that they are as quality-conscious as the next
fellow, but three weeks is real money.
Speaking of software, that industry has accustomed its clients
to accept in-house developed application programs with an average
defect density of one to three defects per hundred lines of code!
With sublime irony, this disastrous record is often blamed on poor
quality consciousness of the builders. That is, those same folks
who are chided for being inclined to "tinker forever with a program,
all in the name of 'Quality'" are also getting blamed for poor
Let's put the blame where it belongs. He who pays the piper is
calling for a low-quality tune. By regularly putting the development
process under extreme time pressure and then accepting poor-quality
products, the software user community has shown its true quality
standard.
All of this may sound like a diatribe against software users and
against the standards of the marketplace in general, but it needn't be
taken that way. We have to assume that the people who pay for our
work are of sound enough mind to make a sensible trade-off between
quality and cost. The point here is that the client's perceived
needs for quality in the product are often not as great as those of the
builder. There is a natural conflict. Reducing the quality of a product
is likely to cause some people not to buy, but the reduced market
penetration that results from virtually any such quality reduction will
often be more than offset by increased profit on each item sold.
Allowing the standard of quality to be set by the buyer, rather
than the builder, is what we call the flight from excellence. A market-
derived quality standard seems to make good sense only as long
as you ignore the effect on the builder's attitude and effectiveness.
22 PEOPLEWARE
In the long run, market-based quality costs more. The lesson
here is,
Quality, far beyond that required by the end user,
is a means to higher productivity.
If you doubt that notion, imagine the following gedanken
experiment: Ask one hundred people on the street what organization
or culture or nation is famous for high quality. We predict that more
than half the people today would answer, "Japan." Now ask a different
hundred people what organization or culture or nation is
famous for high productivity. Again, the majority can be expected
to mention, "Japan." The nation that is an acknowledged quality
leader is also known for its high productivity.
Wait a minute. How is it possible that higher quality coexists
with higher productivity? That flies in the face of the common wisdom
that adding quality to a product means you pay more to build it.
For a clue, read the words of Tajima and Matsubara, two of the
most respected commentators on the Japanese phenomenon:
The trade-off between price and quality does not exist
in Japan. Rather, the idea that high quality brings on
cost reduction is widely accepted.
Quality Is Free, But . . .
Philip Crosby presented this same concept in his book, Quality Is
Free, published in 1979. In this work, Crosby gave numerous
examples and a sound rationale for the idea that letting the builder set
a satisfying quality standard of his own will result in a productivity
gain sufficient to offset the cost of improved quality.
We have an awful inkling that Crosby's book has done more
harm than good in industry. The problem is that the great majority
of managers haven't read it, but everybody has heard the title. The
title has become the whole message. Managers everywhere are
enthusing over quality: "The sky's the limit for quality, we'll have
as much free quality as we can get!" This hardly boils down to a
positive quality consciousness. The attitude is just the opposite of
what Crosby advocates.
QUALITY—IF TIME PERMITS 23
The real message of the linked quality and productivity effects
needs to be presented in slightly different terms:
Quality Is free, but only to those who are willing
to pay heavily for it.
The organization that is willing to budget only zero dollars and
zero cents for quality will always get its money's worth, A policy
of "Quality—If Time Permits" will assure that no quality at all
sneaks into the product.
Hewlett-Packard is an example of an organization that reaps
the benefits from increased productivity due to high, builder-set
quality standards. The company makes a cult of quality. In such an
environment, the argument that more time or money is needed to
produce a high-quality product is generally not heard. The result is
that developers know they are part of a culture that delivers quality
beyond what the marketplace requires. Their sense of quality
identification works for increased job satisfaction and some of the
lowest turnover figures seen anywhere in the industry.
Power of Veto
In some Japanese companies, notably Hitachi Software and parts of
Fujitsu, the project team has an effective power of veto over delivery
of what they believe to be a not-yet-ready product. No matter that
the client would be willing to accept even a substandard product, the
team can insist that delivery wait until its own standards are
achieved. Of course, project managers are under the same pressure
there that they are here: They're being pressed to deliver something,
anything, right away. But enough of a quality culture has been built
up so that these Japanese managers know better than to bully their
workers into settling for lower quality.
Could you give your people power of veto over delivery? Of
course it would take nerves of steel, at least the first time. Your
principal concern would be that Parkinson's Law would be working
against you. That's an important enough subject to warrant a chapter
of its own.
Chapter 5
PARKINSON'S LAW REVISITED
Writing in 1954, the British author C. Northcote Parkinson
introduced the notion that work expands to fill the time allocated for
it, now known as Parkinson's Law.
If you didn't know that few managers receive any management
training at all, you might think there was a school they all went to
for an intensive course on Parkinson's Law and its ramifications.
Even managers that know they know nothing about management
nonetheless cling to that one axiomatic truth governing people and
their attitude toward work: Parkinson's Law. It gives them the
strongest possible conviction that-the only way to get work done at
all is to set an impossibly optimistic delivery date.
Parkinson's Law and Newton's Law
Parkinson's Law is a long way from being axiomatic. It's not a law
in the same sense that Newton's law is a law. Newton was a scientist.
He investigated the gravitational effect according to the strictest
scientific method. His law was only propounded after rigorous
verification and testing. It has stood the test of some two hundred
years of subsequent study.
Parkinson was not a scientist. He collected no data, he probably
didn't even understand the rules of statistical inference. Parkinson
was a humorist. His "law" didn't catch on because it was so
true. It caught on because it was funny.
O/l
PARKINSON'S LAW REVISITED 25
Of course, Parkinson's Law wouldn't be funny if there
weren't a germ of truth in it. Parkinson cites examples of his law as
observed in a fictitious government bureaucracy, some believe patterned
on the British Post Office. Bureaucracies are prone to such
problems, because they give little job-derived satisfaction to their
workers. But you probably don't work in a bureaucracy. Even if
you do, you go to great lengths to make sure that your people are
spared its effects, otherwise they'd never get anything done. The
result is that your people have the possibility of lots ofjob-derived
satisfaction. That leads to a simple truth worth stating:
Parkinson's Law almost certainly doesn't apply to
your people.
Their lives are just too short for any loafing on the job. Since
they enjoy their work, they are disinclined to let it drag on forever—
that would just delay the satisfaction they all hanker for. They
are as eager as you are to get the job done, provided only that they
don't have to compromise their standard of quality.
You Wouldn't Be Saying This If You'd Ever Met
Our Herb
Every manager, at least some time in his or her life, has to deal with
a worker who does seem to be avoiding work, or who seems to
have no standard of quality, or who just can't get the job done.
Doesn't that confirm Parkinson's Law?
In a healthy work environment, the reasons that some people
don't perform are lack of competence, lack of confidence, and lack
of affiliation with others on the project and the project goals. In
none of these cases is schedule pressure liable to help very much.
When a worker seems unable to perform and seems not tacare at all
about the quality of his work, for example, it is a sure sign that the
poor fellow is overwhelmed by the difficulty of the work. He
doesn't need more pressure. What he needs is reassignment, possibly
to another company.
Even on the rare occasion when leaning on someone is the
only option, the manager is the last person to do the leaning. It
works far better when the message comes from the team. We've
seen cases of well-knit teams in which the manager would have had
to get in line to yell at the one person who wasn't pulling along with
everyone else.
We'll have more to say in later chapters about teams and
building a sensible chemistry for team formation. The point here is
not what does work, but what doesn't: Treating your people as
Parkinsonian workers doesn't work. It can only demean and demotivate
them.
Some Data from the University of New South Wales
Of course, the Parkinson's Law mentality is not going to go away
just because we say it ought to. What would help to convert managers
would be some carefully collected data proving that Parkinson's
Law doesn't apply to most workers. (Forget for a moment
that Parkinson supplied no data at all to prove that the law did apply,
he just reiterated it for a few hundred pages.)
Two respected researchers at the University of New South
Wales, Michael Lawrence and Ross Jeffery, run a project survey
every year. They measure live projects in industry according to a
common data collection standard. Each year they focus on a different
aspect of project work. The 1985 survey provided some data
that reflects on the inapplicability of Parkinson's Law. It isn't
exactly the "smoking gun" that completely invalidates the law, but it
ought to be sufficient to raise some doubts.
Lawrence and Jeffery set out to determine the productivity
effect of various estimating methods. They had in mind to prove (or
disprove) the folkloric belief that developers (programmers, in this
case) work harder if they're trying to meet their own estimates. For
each of 103 projects studied, Lawrence and Jeffery formed a
weighted metric of productivity, similar tothe CoCoMoproductivity
metrics advocated by Barry Boehm. They then grouped the sample
into subgroups, depending on how the original estimates we're
made. A partial result is presented in Table 5.1:
PARKINSON'S LAW REVISITED 27
Table 5.1
Productivity by Estimation Approach
(Partial Result)
EFFORT ESTIMATE AVERAGE NUMBER OF
PREPARED BY PRODUCTIVITY PROJECTS
Programmer alone 8.0 19
Supervisor alone 6.6 23
Programmer & supervisor 7.8 16
So far, the results confirm the folklore: Programmers seem to
be a bit more productive when they can do the estimate themselves,
compared to cases in which the manager does it without even consulting
them. When the two do the estimating together, the results
tend to fall in between.
In 21 projects studied that same year, estimates were prepared
by a third party, typically a systems analyst. These cases substantially
outperformed the projects in which estimating was done by a
programmer and/or a supervisor:
Table 5.2
Productivity by Estimation Approach
(Partial Result)
EFFORT ESTIMATE AVERAGE NUIVBEROF
PREPARED BY PRODUCTIVITY PROJECTS
Programmer alone 8.0 19
Supervisor alone 6.6 23
Programmer & supervisor 7.8 16
Systems analyst 9.5 21
These last data points do not confirm the folkloric view at all.
Why should the programmer work harder to meet the analyst's estimate
than he would for even his own? It may be tempting to explain
this away as a simple anomaly in the data. But if you believe as we
do that bad estimates are always a demotivating factor, then this data
doesn't need explaining away at all. The systems analyst tends to be
a better estimator than either the programmer or the supervisor. He
or she typically knows the work in as much detail, but is not hampered
by the natural optimism of the person who's actually going to
do the job or the political and budgetary biases of the boss. Moreover,
systems analysts typically have more estimating experience;
they are able to project the effort more accurately because they've
done more of it in the past and have thus learned their lessons.
Bad estimates, hopelessly tight estimates, sap the builders'
energy. Capers Jones, known for his metric studies of development
projects, puts it this way: "When the schedule for a project is totally
unreasonable and unrealistic, and no amount of overtime can allow it
to be made, the project team becomes angry and frustrated ... and
morale drops to the bottom." It doesn't matter too terribly much
whether the "totally unreasonable and unrealistic" schedule comes
from the boss or from the builders themselves. People just don't
work very effectively when they're locked into a no-win situation.
The most surprising part of the 1985 Jeffery-Lawrence study
appeared at the very end, when they investigated the productivity of
24 projects for which no estimates were prepared at all. These projects
far outperformed all the others:
Table 5.3
Productivity by Estimation Approach
(Full Result)
EFFORT ESTIMATE AVERAGE NUMBER OF
PREPARED BY PRODUCTIVITY PROJECTS
Programmer alone 8.0 19
Supervisor alone 6.6 23
Programmer & supervisor 7.8 16
Systems analyst 9.5 21
(No estimate) 12.0 24
PARKINSON'S LAW REVISITED 29
Projects on which the boss applied no schedule pressure
whatsoever ("Just wake me up when you're done.") had the highest
productivity of all. Of course, none of this proves that Parkinson *s
Law doesn't apply to development workers. But doesn't it make
you wonder?
The decision to apply schedule pressure to a project needs to
be made in much the same way you decide whether or not to punish
your child: If your timing is impeccable so the justification is easily
apparent, then it can help. If you do it all the time, it's just a sign
that you've got troubles of your own.
Variation on a Theme by Parkinson
A slight variation on Parkinson's Law produces something that is
frighteningly true in many organizations:
Organizational busy work tends to expand to fill
the working day.
This effect can start when the company is founded, and become
worse every year. It's part of the reason that very mature companies
are less fun to work for. The few remaining employees of the Dutch
East India Company (founded in 1651 and once the largest company
in the world) now spend forty hours a week filling out forms.
Notice that in this case, it's the company that exhibits Parkmsonian
behavior rather than its employees. We'll return to this theme in
PartlL
Chapter 6
LAETRILE
Laetrile is a colorless liquid pressed from the soft bitter insides
of apricot pits. In Sweden, you can buy the stuff in the grocery
store for about the price of almond extract, and you use it in baking
much as you would any other extract. In Mexico, you can buy it for
fifty dollars a drop to "cure" your fatal cancer. Of course, it doesn't
cure anything. All the evidence demonstrates that it is a cruel fraud.
But since no one else has anything at all to offer them, terminal patients
accept the claims of the laetrile peddlers, no matter how outrageous.
People who are desperate enough don't look very hard at the
evidence.
Similarly, lots of managers are "desperate enough," and their
desperation makes them easy victims of a kind of technical laetrile
that purports to improve productivity. There is seldom any evidence
at all to support the claims of what they buy. They, too, dispense
with evidence because their need is so great.
Lose Fat While Sleeping
One day, in a moment of high silliness, I started clipping
ads for products that claimed to boost productivity
by one hundred percent or more. Within a very short
time, I had quite a pile. The amazing thing was the
diversity of the means advertised to yield big productivity
gains. There were seminars, packaged programs,
methodologies, books, scheduling boards, hardware
monitors, computing languages, and newsletters.
30
LAETRILE 31
Going uptown on the subway that night, I spotted one
final ad on the back of the New York Post. It read,
"Lose Fat While Sleeping." It seemed to fit right in
with the others.
_TRL
We're all under a lot of pressure to improve productivity. The
problem is no longer susceptible to easy solutions, because all the
easy solutions were thought of and applied long ago. Yet some
organizations are doing a lot better than others. We're convinced
that those who do better are not using any particularly advanced
technology. Their better performance can be explained entirely by
their more effective ways of handling people, modifying the workplace
and corporate culture, and implementing some of the measures
that we'll discuss in Parts II through IV. The relative inefficacy of
technology may be a bit discouraging, at least in the short run,
because the kinds of modification to corporate culture we advocate
are hard to apply and slow to take effect. What would be far preferable
is the coupon you cut out of the back pages of a magazine to
send in with a few thousand bucks, so that some marvelous
productivity gimmick will come back to you in the mail. Of course,
it may not do much for you, but then easy non-solutions are often
more attractive than hard solutions.
The Seven Sirens
The false hopes engendered by easy technological non-solutions are
like those Sirens that tempted poor Odysseus. Each one reaches out
to you with her own beguiling message, an attractive fallacy that
leads nowhere. As long as you believe them, you're going to be
reluctant to do the hard work necessary to build a healthy corporate
culture.
The particular Sirens that plague you are a function of what
industry you work in. We've identified seven from the field that we
know best, software development, and we present them below
along with our own responses:
SEVEN FALSEHOPES OFSOFTWAREMANAGEMENT
1. There is some new trick you've missed that could send productivity
soaring.
Response: You are simply not dumb enough to have missed
something so fundamental. You are continually investigating
new approaches and trying out the ones that make the
most sense. None of the measures you've taken or are likely
to take can actually make productivity soar. What they
do, though, is to keep everybody healthy: People like to
keep their minds engaged, to learn, and to improve. The
line that there is some magical innovation out there that
you've missed is a pure fear tactic, employed by those with
a vested interest in selling it.
2. Other managers are getting gains of one hundred percent or
two hundred percent or more!
Response: Forget it. The typical magical tool that's touted
to you is focused on the coding and testing part of the life
cycle. But even if coding and testing went away entirely,
you couldn't expect a gain of one hundred percent. There is
still all the analysis, negotiation, specification, training,
acceptance testing, conversion, and cutover to be done.
3. Technology is moving so swiftly that you're being passed by.
Response: Yes, technology is moving swiftly, but (the high-
tech illusion again) most of what you're doing is not truly
high-tech work. While the machines have changed enormously,
the business of software development has been
rather static. We still spend most of our time working on
requirements and specification, the low-tech part of our
work. Productivity within the software industry has
improved by three to five percent a year, only marginally
better than the steel or automobile industry.
4. Changing languages will give you huge gains.
Response: Languages are important because they affect the
way you think about a problem, but again, they can have
impact only on the implementation part of the project.
LAETRILE 33
Because of their exaggerated claims, some of our newer languages
qualify as laetrile. Sure, it may be better to do a new
application in PowerBuilder., for example, rather than
COBOL, but even before PowerBuilder, there were better
ways than COBOL: niche tools that make inquiry and update
pretty easy. Unless you've been asleep at the switch for the
past few decades, change of a language won't do much for
you. It might give you a five percent gain (nothing to
sneeze at), but not more.
5. Because of the backlog, you need to double productivity
immediately.
Response: The much talked about software backlog is a
myth. We all know that projects cost a lot more at the end
than what we expected them to cost at the beginning. So the
cost of a system that didn't get built this year (because we
didn't have the capacity for it) is optimistically assumed to
be half of what it would actually cost to bui