Negotiation, meaning “discussion intended to produce agreement”, is fundamental to every software project.  (And other projects too – my examples just happen to come from the software industry.)  Developers and customers must reach agreement on what the system is supposed to do.   A wise agreement will define achievable goals and meet the users’ real needs.

How should we reach wise agreements?  How should we reach agreements that create good outcomes for both parties?

There are excellent answers to these questions.  The answers stem from extensive research and apply to all kinds of negotiation, from buying used cars to nuclear disarmament.  They were documented by Roger Fisher and William Ury in their classic book, “Getting to Yes”.  (It still sells over 3000 copies per week, 25 years after it was first published).  Fisher and Ury have applied their findings in many areas, from industrial disputes and corporate mergers to the highest levels of international politics.  They have personally facilitated peace talks in war zones around the world.

Fisher and Ury call their approach “principled negotiation”.  It contains four key elements:

• Separate People from the Problem
• Focus on Interests, not Positions
• Invent Options for Mutual Gain
• Use Objective Criteria

Each is explained in “Getting to Yes”.  Here, I’ll discuss just one – Focussing on Interests, not Positions.

Focus on Interests, not Positions

Kent Beck claimed that customers don’t have requirements, only wishes.  The technique of “Focussing on Interests” offers a theoretical basis for that claim and shows us how to apply it in practice.  “Focussing on Interests” shows how to negotiate requirements, for the benefit of both customer and supplier.

We often think of negotiation as something like this:

Tourist:             How much?

Shopkeeper:     100

Tourist:             I’ll give you 50

Shopkeeper:     90

Tourist:            60

Shopkeeper:    80

Tourist:            70

Shopkeeper:     75

Tourist:            It’s a deal!

That’s “positional bargaining”.  The emphasis is on stating clearly defined positions and splitting the difference in a series of compromises.

In “Getting to Yes”, Fisher and Ury show that we should focus on interests, not positions.  An interest is the underlying need, while a position is just one particular way to satisfy it.  Here’s a real-life example:

In 1978 Egypt and Israel negotiated over the Sinai Peninsula, which Israel had occupied a decade earlier in the 6-day war.  Their positions were completely opposed: they wanted the land and could find no mutually acceptable way divide it between them.  The answer lay in focussing on their interests.

“Israel’s interest lay in security; they did not want Egyptian tanks poised on their border ready to roll across at any time. Egypt’s interest lay in sovereignty; the Sinai had been part of Egypt since the time of the Pharaohs.”

(Fisher and Ury, 1981, p. 41)

While their positions were completely incompatible, their interests were not.  So the Sinai was returned to Egypt (meeting Egypt’s interest in sovereignty) but with large areas demilitarized (meeting Israel’s interest in security).

In software development, we need to identify the interests that lie behind positions. A customer may state their position as, “We must upgrade the system to a 3-tier architecture.”  What is the underlying interest?  Perhaps users complain about slow performance and the customer expects the 3-tier architecture to speed the system up. The stated position isn’t necessarily the only way to satisfy the interest.

I think this is why Kent Beck said “There are no such things as requirements, there are only wishes.”  (Quoted in Crystal Clear)  Explicitly-stated requirements are usually positions.  As such, they are merely one possible way to satisfy the underlying interests.  Software engineers can, and should, seek better ways to satisfy the customer’s interests.

For example, I worked with a customer who insisted their new system needed a web front end.  Having considered their particular requirements, I realised we couldn’t build a web client within the available budget.  It would be cheaper and less risky to run a rich client on each user’s desktop.  Our positions were incompatible: the customer’s wanted a web client and my (unspoken) position was the opposite.  But consider our interests.  The customer’s interest was in minimising the cost of administration.  They knew a web client would allow low-cost central administration.  (In other words, they didn’t actually need a web client, what they needed was low cost of ownership.)  My interest was in minimising the cost of development.  I knew a rich client would deliver more “bang for buck”.   Having identified our interests, we decided on a rich client with browser-based deployment.  It met the customer’s interest in easy deployment and my interest in faster development.  The project was a great success.

Conclusion

Focussing on interests, not positions, is a powerful tool for creating project success.  Software development guru Alistair Cockburn wrote about it here:

“I think I was in the industry 20 years before I ever saw someone renegotiate the requirements the users gave him. I was astonished, because he had turned a large nasty convoluted set of requests into one that we almost had ready. Just by showing up and suggesting to the users they maybe didn’t need what they asked for.”

Why did Alistair wait 20 years to see this?  Why don’t we re-negotiate requirements more often?

Firstly, we omit these negotiations because we are unaware of the difference between interests and positions.  We say “the customer is always right” when we should say “the customer is always right about their interests“.   The customer is not always right about their positions.

Secondly, we omit these negotiations because traditional waterfall processes discourage them.  Consider a traditional software purchase scenario in which the customer issues an RFP (Request for Proposal) to several competing vendors.  The customer states their position (as a set of requirements) and the suppliers reply with their positions (as a price and schedule to implement the requirements).  Each party states their position once.  It’s “one shot” positional negotiation.

Both parties would be better served to engage in dialog about their underlying interests.  Such dialog is encouraged by agile processes.  They promote discussion, provide better opportunities to explore interests, and avoid premature “lock in” of positions.

Fisher and Ury’s style of negotiation is not about winning and losing.  It’s about everybody winning.  It works in family feuds, industrial disputes, corporate mergers… and software development.

Make sure you read their book.

---

See Also:

• building trust through visibility, honesty and competence
• Jeff Patton’s Requirements Considered Harmful.
• Jerry Weinberg gives a nice example here (notice how the best outcome meets interests rather than positions)