|
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! | 
