Best Practices
IEEE Software, Vol. 13, No. 3, May 1996

How to Defend an Unpopular Schedule

Estimating software-product size and of software-project time and resource needs is undoubtedly hard. But once you have made an estimate, you still have to convince your customer or boss to accept it. If the estimated schedule is too long, customers and bosses will pressure you to shorten it--not because of flaws in your analysis but simply because they want it to be shorter. All too often, they succeed, and, as a result, many of us find ourselves working on projects that have been planned from the outset to achieve an unattainable combination of cost, schedule, and functionality. Such projects are programmed to fail. The inevitable late-project consequence is a loud chorus of "Why can't these software guys figure out how to deliver software on time?"

DEFENSELESS DEVELOPERS. Current estimation practices are a problem, but I am convinced that current scheduling practices are the more serious problem. Philip Metzger observed 15 years ago that developers were fairly good at estimating but were poor at defending their estimates (Managing a Programming Project, 2d Ed., 1981). I haven't seen any evidence that developers have gotten any better at defending their estimates in recent years. Several underlying factors come to mind.

Developers tend to be introverts. About three-quarters of developers are introverts compared to about one-third of the general population. Most developers get along with other people fine, but the realm of challenging social interactions is just not their strong suit.

Software schedules are typically set in negotiations between development and management or development and marketing. Gerald Weinberg points out that marketers are often ten years older and negotiate for a living--in other words, they tend to be seasoned, professional negotiators (Quality Software Management, Vol. 3, Congruent Action, Dorset House, 1994). The deck is stacked against developers during schedule negotiations.

Developers tend to be temperamentally opposed to the use of negotiating tricks. Such tricks offend their sense of technical accuracy and fair play. Developers don't want to offer lopsidedly high initial estimates even when they know that customers, marketers, or bosses will start with lopsidedly low bargaining positions.

Because developers need to become better negotiators, I'll spend the rest of this column describing how to negotiate schedules effectively.

PRINCIPLED NEGOTIATION. Start improving your negotiating skills with the principled negotiation strategy described in Getting to Yes (Fisher and Ury, Penguin Books, 1981). This method has several appealing characteristics. It doesn't rely on negotiating tricks, but it explains how to respond to tricks when others use them. It's based on the idea of creating win-win alternatives. You don't try to beat the person you're negotiating with; you try to cooperate so that both of you can win. It's an open strategy. You don't have to fear that the person you're negotiating with has read the same negotiating book and knows the same tricks. The method works best when all the parties involved know about it and use it.

The principled-negotiation strategy consists of four parts, which the following sections relate to software schedule negotiations.

Separate the people from the problem. All negotiations involve people first, interests and positions second. When the negotiators' personalities are at odds--as, for example, developers' and marketers' personalities often are--negotiations can get hung up on personality differences.

Begin by understanding the other side's position. I've seen situations in which non-technical managers had good business reasons for wanting specific deadlines. In one case, a manager felt pressure from the marketing department to produce a software product in 6 months. I told him that the best I could do was 15 months. He said, "I'm not giving you a choice. Our customers are expecting the software in 6 months." I said, "I'm sorry. I wish I could develop the software in 6 months, but 15 months is the best I can do." He just froze and stared at me for two or three minutes.

Why did he freeze? Was he using silence as a negotiating maneuver? Maybe. But I think it was because he felt trapped and powerless. He had promised a six-month development schedule, and now the person who was supposed to lead the development effort was telling him he wouldn't be able to keep that promise.

Most middle managers aren't being stupid or irrational when they insist on a deadline that you know is impossible. They simply don't know enough about the technical work to know that the deadline they want is impossible, and they do know all too well how much pressure they feel from their own bosses, customers, and other departments.

What can you do? Work to improve your relationship with your manager or customer. Be cooperative. Work to set realistic expectations. Position yourself as an advisor on schedule matters, and avoid slipping into the role of adversary. Point out that by refusing to accept an impossible deadline you're really looking out for their best interests. Point to your organization's history of schedule overruns, and tell them that you're unwilling to set either of you up for failure. These points are easiest to make after you've demonstrated a willingness to look for win-win solutions.

Focus on interests, not positions. Suppose you're selling your car in order to buy a new boat, and you've calculated that you need to get $5000 for your car in order to buy the boat. A prospective buyer approaches you and offers $4500. You say, "There's no way I can sell this car for less than $5000." The buyer says, "$4500 is my final offer."

When you negotiate in this way, you focus on positions rather than interests. Positions are bargaining statements that are so narrow that in order for one person to win, the other person has to lose.

Now suppose that the car buyer says, "I truly can't go over $4500, but I happen to know that you're in the market for a new boat, and I happen to be the regional distributor for a boat company. I can get the boat you want for $1000 less than you could get it anywhere else. Now what do you think of my offer?" Well, now the offer sounds pretty good because it will leave you with $500 more than you would have had if the buyer had just agreed to your price.

Focusing on interests rather than positions opens up a world of negotiating possibilities. Your boss might start out saying, "I need Giga-Blat 4.0 in six months," and you might start out saying that you can't deliver it in less than nine months. But your boss's interest might be in keeping a promise made to the sales organization, and your interest might be in working less than 60 hours a week for the next six months. Between the two of you, you should be able to redefine the product so that your boss can keep his promise and you can work a normal schedule.

Software negotiations can become one-dimensional tug-of-wars that focus only on schedules. Don't dig into a position. Make it clear that you're happy to consider a full range of alternatives.

Invent options for mutual gain. Instead of thinking of negotiation as a zero-sum game in which one person wins at the other's expense, think of it as an exercise in creative problem-solving--the truly clever negotiator will find a way for both parties to win.

Your most powerful ally in schedule negotiations is your ability to suggest options. As the technical expert, you can suggest a wealth of possibilities and tradeoffs that the other person probably has no way of knowing about otherwise. The person you're negotiating with is bound to find some of those options more appealing than others.

Here are some options that can shorten the schedule by changing the characteristics of the product you're building: