访谈录：与《最后期限》作者Tom DeMarco的一次面议

//

An interview with Tom DeMarco
访谈录：与《最后期限》作者Tom DeMarco的一次面议

//

About the Book with Tom DeMarco author of The Deadline: A Novel About Project Management

 

[Based in Camden , Maine , Tom DeMarco is a principal of the Atlantic Systems Guild (www.systemsguild.com) and author or coauthor of three other best-selling DH books: Peopleware , Software State-of-the-Art , and Why Does Software Cost So Much? ]

 

This interview originally appeared in Volume VIII, Number 2 of The Dorset House Quarterly (DHQ), a free newsletter for readers of Dorset House books. Call (800) 342-6657 or (212) 620-4053 to request a subscription.

 

See also: http://www.atlsysguild.com for more about Tom DeMarco, his books and Guild consulting services.

 

*********************************************************************

 

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?

 

TDM: 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?

 

TDM: 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?

 

TDM: 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, over documentation, 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.

 

TDM: 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?

 

TDM: 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: And we have the good fortune to read it. Tom, let’s continue this on the Web! Thank you.

 

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?

 

TDM: Sorry. There is no way. Belinda’s talent 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?

 

TDM: 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?

 

TDM: 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?

 

TDM: 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?

 

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