|
DHQ: Your new book, The Deadline,
is called a "novel about project management."
What advantages did you find in writing a novel
instead of using a nonfiction genre like the essay?
DeMARCO: What I would have killed
for when I was a young manager was an opportunity
to be a fly on the wall and observe a really gifted
manager do his or her job. How would that manager
handle the dozens of sticky little problems that
were then grinding me down? How would he or she
deal with problem workers, fragmentation, low
motivation, conflicting goals, and pressure from
above? The novel form offered me a way to make
that fly-on-the-wall experience available to others.
If the novel works as I hope it will, reading
it should almost be the equivalent of adding two
great years to your management experience.
DHQ: How does Mr. Tompkins, the protagonist
of the story, wind up in Morovia developing software
for a former Soviet state? And where exactly is
Morovia?
DeMARCO: Let me take the second
question first. Morovia is a peaceful, pretty
little backwater nation tucked into the lower
Balkans, on the coast of the Ionian Sea. Coming
out of a long period of political repression,
like the rest of the Soviet bloc, it suddenly
finds itself full of potential for new ideas,
new industries, and new opportunity. I placed
the action there because I wanted to put Mr. Tompkins
in a situation where starting a whole software
industry from scratch would be conceivable.
But I also wanted the place to have a dark enough
history so that the use of some heavy-handed methods
might be part of the game. Poor Mr. Tompkins,
you see, doesn't actually accept the job; he gets
kidnapped. And the motivation provided from above
is starkly effective: He is to finish the job
on schedule or pay for it with his life. So we
have a manager who has his very survival staked
on a project deadline. How would you manage a
project if your life depended on making the deadline?
That's the question he is faced with. I'll give
you a tiny hint about his answer: He does not
decide to improve his organization's CMM level.
DHQ: One of the lessons in the book about
deadlines is that extreme time pressure may accelerate
progress initially, but it soon hits a plateau,
in which further pressure is ineffective. What can
managers learn from this dynamic?
DeMARCO: The first thing they can
learn is what Tim
Lister has been telling us for years now:
"People under time pressure don't think faster."
Like much of what Tim tells us, this seems patently
obvious after he's said it. But before he pointed
it out, most of us (and most of the software industry)
didn't have a clue. Of course people don't think
faster, they can't. And since their work is think-intensive,
they can't do the work faster. So the effects
of pressure can only be felt in a few very limited
ways: They can waste less time, they can put off
other work, or they can steal time from their
personal lives. The first of these effects is
good, but not worth a lot, since most software
developers were trying not to waste time, even
before the pressure was put on. Putting off other
work is productivity neutral, since the work has
to be done eventually anyway. And stealing time
from your family is a long-term disaster, because
you burn out.
Poor managers apply a lot of pressure, because
they don't know what else to do. Great managers
apply very little. They know the limitations of
pressure. They spend most of their energies doing
the hard work of management: motivation, team
formation, and design and re-design of the organization
to eliminate waste (bloated meetings, overdocumentation,
and pointless regimentation).
DHQ: Mr. Tompkins sets up a Project Management
Laboratory, in which each of six software products
is developed by a set of competing teams. Tell us
about this experiment and its appeal to project
managers.
DeMARCO: Virtually all the data
we have today about project dynamics is data collected
from live projects whose purpose was to do something
other than teach us about project dynamics. Conspicuously
missing from our history is that bread-and-butter
tool for understanding causality: the controlled
experiment.
Since Mr. Tompkins has little time but a ton
of people, he decides to hedge his bets. He sets
up rival projects to do the same work. (Even if
only one of them finishes before the deadline,
his bacon is saved.) Then he sets out to alter
some of the variables, hoping to stumble upon
an advantage that will enable one or a few of
the teams to outperform. In the process, he is
effectively running a controlled experiment. If
he lives, he realizes, he's going to understand
project dynamics a lot better than he did before.
DHQ: Most of the chapters in The Deadline
contain entries from Mr. Tompkins' project management
journal. Were these the seeds of the storyline?
or were they written after you'd finished the chapters?
DeMARCO: Most of them came out
of my own journal. They were lessons that I learned
the hard way, just as Mr. Tompkins does. Though
I suffered the hard knocks that led to these journal
entries, I was often too dim or too bruised to
see the lessons myself. It has been my great good
fortune over the years to be surrounded by people
who were magnificent abstractors: They could say,
"Look, there's a pattern here." And
my own contribution has been that every time they
made me go Ahah, I had the good sense to write
it down in my journal.
DHQ: One of the main characters, Belinda
Binda—a brilliant-but-burned-out project manager—takes
the lead in selecting team managers by gut feel,
rather than by resume alone. How can readers apply
this technique in real life?
DeMARCO: Sorry. There is no way.
Belinda's talent is has nothing to do with technique.
She's just got a great gut. And she knows enough
to trust it. Hiring is the most important thing
a manager does. Some people do it superbly and
others don't. I don't. But I have worked with
great managers for nearly thirty years now, and
I have seen their guts at work. In this one respect
at least, managers are born, not made.
DHQ: There are many colorful characters
in the novel, especially among the consultants who
are enlisted to counsel Mr. Tompkins. Some of these
consultants—such as Aristotle Kenoros, Harry
Winnipeg, T. Johns Caporous, and the Great Yordini—seem
remarkably like some of the software industry's
gurus. Are there real-life counterparts to these
characters?
DeMARCO: Of course not.
DHQ: One of the consultant characters
in the novel introduces the idea of using function
points. What are function points, and how are they
used?
DeMARCO: Function points are the
most essential metric in common use today. Derived
from the specification, the function metric is
the earliest and most solid quantification of
project size. You may decide not to use function
points for one reason or another on your next
project, but not knowing about the concept at
all or not being able to apply it would be a foolish
and dangerous kind of ignorance.
DHQ: Morovia's Tyrant explains to Tompkins
that the software products under development are
meant to be near-copies of extremely successful
software products. His idea is that imitation is
legal, short of copying the code outright, and that
he can give away the copycat products as updates
to the originals (and still somehow make a profit).
Is this attitude toward development prevalent today?
What does it say about the software market and the
future of software?
DeMARCO: As MIT economist Lester
Thurow has pointed out: "In the 19th Century,
if you built a better mousetrap, the world would
beat a pathway to your door; today building a
better mousetrap is not as important as building
one more cheaply." The emphasis has shifted
from invention capacity to production ingenuity.
That explains why it was the Dutch who invented
the CD player and the Americans who invented the
VCR, but it was the Japanese who got rich on both
of them. So too in software. Ideas are no longer
king. If they were, Apple would have eaten Microsoft's
lunch instead of the other way around.
DHQ: In various parts of the novel, Mr.
Tompkins deceives his boss, the sinister Minister
Belok. He lets Belok believe that crazy schedules
are going to be met and that certain brutal management
directives imposed from above are really being implemented
by Tompkins. Under what circumstances is deceit
justifiable by subordinate managers? When should
a manager "just say no" or quit in protest,
instead of using subterfuge?
DeMARCO: Most of what we learned
in kindergarten about truth-telling and honorable
comportment are reasonable guides to how managers
need to behave. That would certainly be true in
any kind of healthy organization. But Mr. Tompkins
finds himself in circumstances that simply do
not let him behave the way he knows he should:
Belok silenced him with a wave of the hand.
"You better be on schedule with those products,
Tompkins You don't want to be here in front
of me if you are not. It would be one damn sorry
day for you if you had stand here and tell me
that you weren't going to make the June 1st
delivery for all six products. One very very
sorry day indeed. I am not kidding about this.
Now, are you on schedule?"
"Sure," Mr. Tompkins said, his voice
flat.
I wish that this sort of thing happened only
in novels. But it doesn't. Most of us have been
in almost exactly that situation at one time or
another. What should you do with a Belok-like
superior? Hunker down, I guess, and try to survive
until a reasonable exit point presents itself.
Grin and bear it for now, and get your revenge
later by publishing it in a book.
DHQ: Thanks, Tom!
|
