A good place to start improving your negotiating skills is the principled negotiation method described in Getting to Yes (Fisher and Ury 1981). This method has several characteristics that I find appealing. 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 that deal with people, interests, options, and criteria:

Each of these is described in the following sections.

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 had cases in which a non-technical manager had good business reasons for wanting a specific deadline. In one case, a manager felt pressure from the marketing organization and his boss to produce what was probably a 15-month project in 6 months. He told me that he had to have the software 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. But 15 months is the best I can do." He just froze and stared at me for 2 or 3 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 his boss a 6-month development schedule, and now the person who was supposed to head the project was telling him he couldn't keep his promise.

Understand that managers can be trapped by their organization's outdated policies. Some organizations fund software projects in ways that are essentially incompatible with the way software is developed. They don't allow managers to ask for funding just to develop the product concept and come up with a good cost estimate. To get enough funding to do a decent estimate, managers have to get funding for the whole project. By the time they get a decent estimate, it can be embarrassing or even career-threatening to go back and ask for the right amount of funding. People at the highest levels of such organizations need to hear the software-estimation story so that they can institute sensible funding practices.

Most middle managers aren't 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 it's impossible, or they know all too well how much pressure they feel from their own bosses, customers, or people higher up in the organization.

What can you do? Work to improve the relationship with your manager or customer. Be cooperative. Work to set realistic expectations. Be sure that everyone understands the software-estimation story. Be an advisor on schedule matters, and avoid slipping into the role of adversary. Suggest ways to change the project that will reduce the schedule, but hold firm to not just writing down a different date.

It's also useful to try to take emotions out of the negotiating equation. Sometimes the easiest way to do that is to let the other people blow off steam. Don't react emotionally to their emotions. Invite them to express themselves fully. Say something like, "I can see that those are all serious concerns, and I want to be sure I understand your position. What else can you tell me about your situation?" When they are done, acknowledge their emotions and reiterate your commitment to find a win-win solution. The other parts of principled negotiation will help you to follow through on that commitment.

Suppose you're selling your car in order to buy a new boat, and you've figured that you need to get $5000 for your car in order to buy the boat you want. A prospective buyer approaches you and offers $4500. You say, "There's no way I can part with 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 really 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 big boat company. I can get the boat you want for $1000 less than you can get it from any dealer. Now what do you think about my offer?" Well, now the offer sounds pretty good because it will leave you with $500 more than you would have gotten if the buyer had just agreed to your price.

Underlying interests are broader than bargaining positions, and focusing on them opens up a world of negotiating possibilities. Your boss might start out by saying, "I need Giga-Blat 4.0 in 6 months," and you might know immediately that you can't deliver it in less than 9 months. Your boss's interest might be keeping a promise made to the sales organization, and your interest might be working less than 60 hours a week for the next 6 months. Between the two of you, you might be able to create a product that would satisfy the sales organization and would be deliverable within 6 months. If you focus on interests, you're more likely to find a win-win solution than if you dig into bargaining positions.

One of the major problems with schedule negotiations is that they tend to become one-dimensional, focusing only on the schedule. Don't get dug into a position. Make it clear that you're willing to consider a full-range of alternatives—just not pie-in-the-sky options. If other people have dug themselves into demanding a specific schedule, here are some points you can use to dislodge them:

Appeal to true development speed. Point out that the worst fault of overly optimistic schedules is that they undermine actual development speed. Explain the negative effects of overly optimistic scheduling that were described in Overly Optimistic Scheduling. True rapid development requires that you be firmly connected to reality, including to a realistic schedule.

Appeal to increasing the chance of success. Point out that you have estimated the most likely completion date and that you already have only a 50/50 chance of meeting that. Shortening the schedule will further reduce your chances of completing on time.

Invoke your organization's track record. Point to your organization's history of underestimating projects, coming in late, and all the problems that lateness has caused. Appeal to the other person's good sense not to do the same thing again.

Rather than thinking of negotiating 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 negotiating ally in schedule negotiations is your ability to generate options that the other person has no way of knowing about. You hold the key to a vault of technical knowledge, and that puts the responsibility for generating creative solutions more on your shoulders than on the nontechnical person you're negotiating with. It's your role to explain the full range of possibilities and trade-offs.

I find it useful to think about how many degrees of freedom there are in planning a software project. The basic degrees of freedom are defined by the schedule, cost, and product triangle. You have to keep the three corners in balance for the project to succeed. But there are infinite variations on that triangle, and the person you're negotiating with might find some of those variations to be a lot more appealing than others. Here are some of the degrees of freedom you might suggest related to the product itself:

Here are some degrees of freedom related to project resources:

Here are some degrees of freedom you can suggest related to the project's schedule:

You can propose a few additional degrees of freedom in certain circumstances. They can make a difference in development time, but they also tend to be political hot potatoes. Don't bring them up unless you know the person on the other side of the table is already sympathetic to your cause.

Whatever you do, don't agree to a lopsided schedule-cost-product triangle. Remember that once you've settled on a feature set, the size of the triangle is practically a law of physics—the three corners have to be in balance.

Throughout the negotiations, focus on what you can do and avoid getting stuck on what you can't. If you're given an impossible combination of feature set, resources, and schedule, say, "I can deliver the whole feature set with my current team 4 weeks later than you want it. Or I could add a person to the team and deliver the whole feature set when you want it. Or I can cut features X, Y, and Z and deliver the rest with my current team by the time you want it."

The key is to take attention away from a shouting match like this one: I can't do it. "Yes you can." No I can't. "Can!" Can't! Lay out a set of options, and focus your discussion on what you can do.

One warning: In the cooperative, brainstorming atmosphere that arises from this kind of free-wheeling discussion, it's easy to agree to a solution that seems like a good idea at the time but by the next morning seems like a bad deal. Don't make any hard commitments to new options until you've had enough time to analyze them quietly by yourself.

One of the oddest aspects of our business is that when careful estimation produces estimates that are notably longer than desired, the customer or manager will often simply disregard the estimate (Jones 1994). They'll do that even when the estimate comes from an estimation tool or an outside estimation expert—and even when the organization has a history of overrunning its estimates. Questioning an estimate is a valid and useful practice. Throwing it out the window and replacing it with wishful thinking is not.

A key to breaking deadlocks with principled negotiations is the use of objective criteria. The alternative is to break negotiation deadlocks based on whoever has the most willpower. I've seen schedules for million-dollar projects decided on the basis of which person could stare the longest without blinking. Most organizations will be better off using a more principled approach.

In principled negotiation, when you reach a deadlock, you search for objective criteria you can use to break the deadlock. You reason with the other people about which criteria are most appropriate, and you keep an open mind about criteria they suggest. Most important, you don't yield to pressure, only to principle.

Here are some guidelines for keeping schedule negotiations focused on principles and not just desires.

Don't negotiate the estimate itself. You can negotiate the inputs to the estimate—the degrees of freedom described in the previous section—but not the estimate itself. As Figure 9-8 suggests, treat the estimate as something that's determined from those inputs almost by a law of nature. Be extremely open to changing the inputs and be ready to offer alternatives, but match your flexibility in those areas with a firm stance on the estimate itself.

Figure 9-8. Treating an estimate as something determined by a law of nature. You can negotiate the inputs, but you can't change the output without changing the inputs.

Suppose you're negotiating with an in-house customer. You could say something like this: "This is my best estimate. I can write a different date on a piece of paper, but that won't be a valid estimate. I can write a bigger number in my checkbook, too, but that doesn't mean that I'll have any more money. I've already given the team only about a 50-percent chance of delivering the software on time. Planning for a shorter schedule won't shorten the amount of time it will take them to create the product you want. It will just increase the risk of being late."

Point out that by refusing to accept an impossible deadline you're really looking out for your customer's best interests. Point to your organization's history of schedule overruns, and tell the in-house customer that you're unwilling to set either of you up for failure. It's easy to make this argument once you've demonstrated your willingness to look for win-win solutions.

Insist that the estimate be prepared by a qualified party. Sometimes negotiations produce the absurd situation in which customers who have no idea how to build a software system nevertheless claim to know how long it will take to build it. Insist that the estimate be prepared by someone with appropriate qualifications. That will often be you.

Some organizations have had good success creating an independent estimation group. Those groups are effective because they do not have a vested interest either in delivering the product in the shortest possible time or in avoiding hard work. If negotiations become deadlocked on the topic of the estimate, propose submitting the estimate to a third party and pledge to accept their results. Ask your negotiation foe to pledge to do the same.

A variation on this theme is to bring in a consultant or noted authority to review your schedule. (An unfamiliar expert sometimes has more credibility than a familiar one.) Some organizations have also had success using software-estimation tools. They've found that once developers calibrate the estimation tool for a specific project, the tool allows them to easily and objectively explore the effects of different options in an unbiased way.

Insist on a rational estimation procedure. Chapter 8, Chapter 8, explains the basis for creating software project estimates. Insist that the procedure that is used to create the estimate comply with the following guidelines:

Don't bow to the pressure to commit to impossible deadlines. That short-term fix damages your long-term credibility. No one really benefits from pretending that you can meet an impossible schedule, even though sometimes people think they do. Improve your credibility by pushing for solutions that respond to the real business needs of your bosses and customers.

Weather the storm. Although people have different tolerances for withstanding pressure, if your customers, managers, or marketers want you to change your estimate without also changing the feature set or resources, I think the best approach is to politely and firmly stand by your estimate. Batten down the hatches and endure the thunderstorm of an unwelcome estimate early in the project rather than the hurricane of schedule slips and cost overruns later on.