23.3 Problem Solving and Principled Negotiation

23.3 Problem Solving and Principled Negotiation

In my 1996 book Rapid Development, I described estimation discussions as negotiations. As the years have gone by, I have become less and less convinced that negotiation is the most constructive way to view the discussions that occur around estimates of cost, schedule, and functionality.

Negotiation involves parties who have competing interests. The point is to divide a pie between two or more parties. In antagonistic negotiations, each side tries to get as much of the pie as possible, and every bit of pie that one side gets comes at the other side's expense. In collaborative negotiations, each side looks for ways to make the pie larger, but in the end, the pie still gets divided.

In software negotiations, there is no pie to divide. When we're negotiating with sales, marketing, or executives, we're all sitting on the same side of the table. Far from being a case of "they win and we lose," it's a case of "we all win" or "we all lose." Our interests are the same. We either lay the groundwork for the software project to succeed, which is a success for everyone, or we create the conditions for its failure, which is a failure for everyone. Thus, I can no longer see what is being negotiated in software estimate discussions.

A better model for the discussions between technical staff, sales, marketing, executives, and other stakeholders is collaborative problem solving. We all work together, share our expertise in different areas, and create a solution that will ultimately work for the best interests of the business.

Tip #114 

Treat estimation discussions as problem solving, not negotiation. Recognize that all project stakeholders are on the same side of the table. Everyone wins, or everyone loses.

Once we, the technical staff, recognize that we are problem solving, we create a constructive frame of mind in which to have discussions about targets, estimates, and commitments. The trick now becomes how to get the other stakeholders into that frame of mind.

A Problem-Solving Approach to Negotiation

Even if we know that we are problem solving, the people we're discussing the estimate with might think they are negotiating. People negotiate in many different ways. Some strategies are based on strength of bargaining position, intimidation, friendship, or a desire to gain approval or curry favor. And some strategies rely on deception or other skillful psychological maneuvers.

Because estimation discussions tend to roam between estimates, targets, commitments, and plans, the discussions can't be tidily pigeonholed as pure negotiation or pure problem solving. You'll usually find yourself engaging in some elements of both problem solving and negotiation.

A good strategy that bridges the divide between negotiating and problem solving is the principled-negotiation method described in Getting to Yes (Fisher and Ury 1991). The method is called negotiation, but the participants are viewed as problem solvers. This method doesn't rely on negotiating tricks, and it explains how to respond to tricks when others use them. It's based on the idea of creating win-win alternatives. The method works well when only you are using it, and it works even better when the other side is using it too.

The strategy consists of four parts:

• Separate the people from the problem.

• Focus on interests, not positions.

• Invent options for mutual gain.

• Insist on using objective criteria.

Each of these is described in the following sections.

Separate the People from the Problem

Estimate discussions involve people first, interests and positions second. When the stakeholders' personalities are at odds—as, for example, the personalities of technical staff and marketers often are—discussions can get hung up on personality differences.

Begin by understanding the other side's position. 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 requirements and plans and come up with a good estimate. To get enough funding to do a meaningful estimate, managers have to get funding for the whole project. By the time they get a meaningful 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 better understand software estimation so that they can institute funding practices that support effective software development.

In these discussions, you might think of yourself as an advisor on software estimation, and thereby avoid slipping into the role of adversary. Keep pulling the focus of the discussion back to what is best for the business.

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 our company's position. What else can you tell me about our business situation?" When they are done explaining, acknowledge what they've told you and reiterate your commitment to find a solution that's good for your organization. The other parts of principled negotiation will help you to follow through on that commitment.

Tip #115 

Attack the problem, not the people.

Focus on Interests, Not Positions

Suppose you're selling your car in order to buy a new boat, and you've figured that you need to get $10,000 for your car to buy the boat you want. A prospective buyer approaches you and offers $9,000. You say, "There's no way I can part with this car for less than $10,000." The buyer says, "I can go to $9,000, but that's my limit."

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 $9,000, 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 $2,000 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 $1,000 more than you would have gotten if the buyer had just agreed to the price of your opening position.

Underlying interests are broader than bargaining positions, and focusing on them opens up a world of negotiating possibilities. Consider the following scenario:

EXECUTIVE: We need Giga-Blat 4.0 in 6 months.

TECHNICAL LEAD: We've estimated the project carefully. Unfortunately, our estimates show that we can't deliver it in less than 8 months.

EXECUTIVE: That's not good enough. We really need it in 6 months.

TECHNICAL LEAD: Do we really need all the functionality that's currently required? If we could cut enough functionality, we could deliver it in 6 months.

EXECUTIVE: We can't cut functionality. We've already cut features to the bone on this release. We need all the features, and we need them within 6 months.

TECHNICAL LEAD: What's the major factor that's driving the 6-month schedule? Maybe we can find a creative solution.

EXECUTIVE: The annual trade show for our industry is in 6 months. If we miss the trade show, we've missed our chance to demo the software to many of our key accounts. That will effectively push back our sales cycle by a whole year.

TECHNICAL LEAD: I really can't commit to delivering the final software in time for the trade show. But I can commit to having a beta version ready for the trade show, and I can provide a tester who knows where all the problems are and who can run the software during the show so that it doesn't break. How does that sound?

EXECUTIVE: If you can promise the software won't crash, that will work fine.

TECHNICAL LEAD: No problem.

One major difference between typical negotiating and problem solving via discussion of interests is that negotiations tend to get frozen into positions. The turning point in this dialogue came when the technical lead asked, "What's the major factor that's driving the six-month schedule?" That switched the dialogue from arguing about positions to trying to understand the company's interests and solve the underlying business problem.. When you focus on interests, you're more likely to find a win-win solution.

Invent Options for Mutual Gain

Your most powerful negotiating ally in estimate discussions is not your estimate; it's your ability to generate planning options that nontechnical stakeholders have 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 anyone else's. It's your role to propose the full range of possibilities and tradeoffs.

Table 23-2 lists some of the planning options you might suggest to break a logjam in your discussion.

Table 23-2: Planning Options That Might Help Break a Discussion Deadlock

Feature-Related Options

• Move some of the desired functionality into version 2. Few people need all of what they asked for exactly when they asked for it.

• Use an iterative approach. Deliver the software in versions 0.2, 0.4, 0.6, 0.8, and 1.0, with the most important functionality coming first.

• Cut features altogether, with an emphasis on cutting the features that are most expensive.

• Use t-shirt sizing to focus on delivering the features with the highest net business value.

• Polish some features less. Implement them to some degree, but make them less fancy.

• Relax the detailed requirements for each feature. Define your mission as getting as close as possible to the requirements through the use of existing components.

• Build a feature-oriented Cone of Uncertainty. Define some features as "definitely in," some as "definitely out," and some as "possible." Propose a plan for tightening up the Feature Cone of Uncertainty as the project progresses.

Resource-Related Options

• Add more developers or testers, if it's early in the schedule.

• Add contract staff, if it's early in the project.

• Add higher-output technical staff (for example, subject-area experts or more senior developers).

• Add more administrative support.

• Increase the degree of developer support.

• Increase the level of end-user or customer involvement. Devote a full-time end-user to the project who is authorized to make binding decisions about the software's features.

• Increase the level of executive involvement to speed decision making.

• Suggest that another team do part of the work (but watch out for the extra integration issues this will create).

• Assign resources 100% to the project. Don't divide their attention between the new project and an old project or between multiple new projects.

Schedule-Related Options

• Provide an "estimate road map" that maps out a plan for reestimating and tightening up the estimates.

• Use estimation ranges or coarse estimates and refine them as the project progresses.

• Look for ways to plan toward specific cost, schedule, or feature goals as you refine the requirements and plans.

• Agree to delay making a specific commitment until you complete the next phase of the project (that is, the work required to narrow the Cone of Uncertainty).

• Do one or two short iterations to calibrate productivity, and then make a commitment based on the team's actual productivity.

The key is to prevent 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 those options. Don't include impossible options in the set you present. Avoid saying, "No, I can't do that"; instead, redirect the discussion toward what you can do. The more options you generate that support doing what's best for the organization, the easier it will be to show that you're on the same side of the table as the person you're problem solving with.

Tip #116 

Generate as many planning options as you can to support your organization's goals.

One warning: In the cooperative, brainstorming atmosphere that arises from the free-wheeling problem-solving 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. The cautions in Section 4.8, "Off-the-Cuff Estimates," apply to this situation. Don't make any hard commitments to new options until you've had enough time to analyze them quietly by yourself.

Tip #117 

As you foster an atmosphere of collaborative problem solving, don't make any commitments based on off-the-cuff estimates.

Insist on Using Objective Criteria

One of the oddest aspects of our business is that when careful estimation produces estimates that are notably larger than desired, the customer or manager will often simply disregard the estimate (Jones 1994). He or she might 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.

When principled negotiation is infused with problem solving, you seek "a wise agreement as judged by any objective standard." You can reason with the other people about which objective standards are most appropriate, and you keep an open mind about standards they suggest. Most important, you don't yield to pressure, only to principle. To support discussions based on principle, it's important to recognize who is the most sensible owner for each specific part of the discussion.

Technical Staff and Technical Management Own the Estimate

You are in the best position to understand the technical scope of work and to create the estimates for it. Therefore, you should be the primary authority on the estimates.

Nontechnical Stakeholders Own the Target

Executives and sales and marketing people are usually in the best position to understand the needs and priorities of the business. Therefore, they should be the primary authorities on the business targets.

Technical Staff and Nontechnical Staff Jointly Own the Commitment

The commitment is where the targets and the estimates must ultimately be resolved. If you can reach agreement that you are the authority for the estimate and other stakeholders are the authority for the targets, most of the discussion will then naturally focus on the commitment. The overriding principle should be to reach agreement about what commitment will be best for the organization.

During these discussions, keep the following points in mind:

Don't negotiate the estimate itself Clarify the difference between the estimate and the commitment. Keep moving the discussion back toward making a commitment that's in the organization's best interests.

Insist that the estimate be prepared by a qualified party The most qualified estimator will often be you. In other cases, the qualified party might be an independent estimation group. Those groups are effective because they do not have a vested interest either in delivering the software in the shortest possible time or in avoiding hard work. If discussions become deadlocked on the topic of the estimate itself, propose submitting the estimate to a third party and pledge to accept the results. Ask other parties in the discussion to agree to do the same.

A variation on this theme is to bring in a consultant or outside expert 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 technical staff 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.

Refer to your organization's standardized estimation procedure You can avoid arguing about who creates the estimate most of the time if you've previously adopted a standardized estimation procedure. It's then easy to say, "Our procedure doesn't allow us to negotiate the estimate itself. Let's talk about the assumptions in the estimate (like project size) and the level of risk that it makes sense for the organization to take on in the commitment for this project."

Weather the storm Although people have different tolerances for withstanding pressure, if your customers, managers, marketers, or other stakeholders want you to commit to impossible goals, I think the best approach is to politely and firmly stand by your principles. 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.

No one really benefits from pretending that impossible goals can be met, 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. Provide predictability and improve your organization's ability to meet its commitments.

Tip #118 

Resolve discussion deadlocks by returning to the question of, "What will be best for our organization?"