Method_2of5: Contract (negotiation)

The five articles in this series have a single purpose: share small outlines of the approach I used in various consulting and service management activities.

This blog is also a “draft” for other publications, and therefore I decided to share also methodology segments, developed through activities.

Five activities, each activity with a 10-points “plan outline”, followed by a discussion on how that could be supported by a specific job position (that I either observed or helped to create).

The five activities are:

  1. crisis (resolution)
  2. contract (negotiation)
  3. confidentiality (monitoring)
  4. service (management)
  5. project (management)

A caveat: I first developed this appraoch in business and non-business activities out of necessity, and then


Negotiating a contract is not rocket science- but I often observed that most of the negotiating mistakes (e.g. extending the negotiation process with unpaid activities that should be part of the ensuing activities) are linked to a mismatch between the expectations of those involved.

Sometimes, as in many communication processes, the mismatch is both intentional and used to mislead.

A typical sign is when the “buying” side keeps extending the qualification process from the capability to deliver, to the implementation.

In IT, this could go as far as asking the potential supplier to deliver full specifications before any formal contractual engagement has been reached.

In change management and marketing, it is much easier to see when the customer extends the negotiation, by asking to propose “concepts”, or “proposed detailed approach”, and so on, and so forth.

My experience in contract negotiations? First in software development, as a support to those preparing a technical offer (in 1986) for a large custom project (at the time, I was told that it was to be the first fixed price project in Andersen in Italy), then on packages/licensing negotiations, and eventually just on services- or a mix of the three.

Negotiating a contract does not necessarily imply creating a new contract- in organizational development and IT consulting, it is quite common that, while the customer has the needs, it lacks the internal expertise to either express the needs or the desired results.

Therefore, a series of contracts is actually used to build up to the point where a contract introducing the main change or the technology can be negotiated.

Whenever I was involved in a negotiation, before looking at the financial side, I tried to obtain more information about the customer, its structure, and… its history with other suppliers.

Often, when I was called to negotiate a new contract on an existing customer, it was easier to obtain the information from the customer than from the company I was representing: I call it excessive compartmentalization- or also excessive pride from those previously involved.

A basic need to negotiate is… to have access to the information- my worst nightmare was when, after gradually building up a converging consensus, and getting close to signing… the company I represented decided to pull out of the the hat some “unbalancing” information.

In some cultures this would generate an immediate response from the (now lost) customer: if you are unreliable before even signing the contract, what can be expect later on?

In other cultures, there is no need to share the shock and disagreement- you simply can consider the negotiation close, as you should never bring “surprises” at the table, and the negotiation is postponed to a next meeting yet to be scheduled- that never will.

I had both experiences- and, frankly, it is just a matter of recognizing the signs.

Of course, coming from consulting and IT, “negotiation” is really split in two paths- negotiating with a long-term perspective, i.e. the first of a series of contracts, or negotiating a “one-off”, e.g. to provide a specific service.

As for software packages- it depends on both the customer and the supplier, as some software suppliers have pricing models that include the long-term relationship perspective, e.g. by defining an annual maintenance fee that is linked to the length of the agreement.

But that you negotiate a new contract, or take over an existing one, e.g. by expanding its scope, a main issue is the sustainability of the contract- for both you and the customer.

Sustainability is a complex issue, and imparts on the structure (e.g. fixed price, outsourcing) and content (service, product, people)- but while it is too complex to stay within my self-imposed writing limits, it all boils down to the same question.

Do you have enough reliable information about your own organization/supply chain, your customer, all those involved, and enough confidence in the ability to control the context of the activity that you are proposing?

If yes, any contract form or shape is fine- provided that you both agree.

If not, you have to assess the risk and identify also the “degrees of freedom”: it would be worthless to sign a contract that binds you, but whose execution implies a willingness from your customer to disclose information that… they do not have access to, as it required a second supplier to be willing to complete on time the last project- after which, you will replace them…

A typical example? When you sign a contract to do something in a fixed amount of time, for a fixed price- without having the knowledge needed to deliver (or the knowledge about what you are really to deliver!).

I lost count on how many times I was called in for desperate negotiations, that had been dragging forever, or were almost lost.

I was able to help the sales side close not because I was smarter than they were, but because, without knowing, they had almost all the information that I needed.

Coming from outside, I was able to see the ongoing negotiation for what it was, and I had a simple approach to follow.

About the structure: I never understood those negotiating on price only- since my first negotiation (maybe because I saw plenty done just on price, and because my first large project was on automating payments to suppliers in the automotive industry), I structured price around budget line items, and then the overall price.

With this approach, if you reduce the price, you have to remove something- you can still apply a bottom line discount, but then it is clear that it is a global commercial discount, not a differential pricelist (as that would eventually leak, and other customers would ask the same- I saw it often).

Last but not least: some of the points in the outline are shared with the first article- contract negotiation and crisis resolution are usually intertwined.


  1. listen before you talk: take mental note of both what is said, and how is said, as this could be useful in identifying the real critical issue
  2. collect the pieces if you want to negotiate a contract, you need to collect information, not just take at face value what is told to you- and, sometimes, the information that you need requires some work
  3. identify the opening no, it is not just the old “unique selling proposition”- it is more a matter of finding the keystone of your contract, what would be the differentiating point vs. potential competitors (or not signing the contract)
  4. assemble the edifice a contract is a communication tool: it is not written for the lawyers, but should be understandable for all those involved in its execution; the moment people needs to get back to the contract to check a comma or a clause, it is the moment when your team leaders (on a service or project) did not see the signs of an incoming crisis; and this is the reason why a contract should be readable and usable
  5. drum up the argument you have to convert your argument, the “why” the customer should sign the contract into something that the customer can defend in her/his own structure; I saw too many contracts won by persuasion, but with no transfer to the customer of what (s)he needed to see the contract as her/his contract
  6. shifting from the past to the future this point is always useful, but it is even more critical when your contract is the last one in a series of contracts trying to deliver a result (e.g. an organizational change that has been attempted time and again); and this is why the first and second point are important: a contract introduces a change- also if you deliver just pencils- you need to sell based on their past joined with the present contract to deliver their future results
  7. bring through business case/prototype or case studies/visits or both this, of course, is a touchy issue: some customers are constantly asking for proposals- and never signing a contract; in most cases, you can balance off the costs of this phase (notably in software or change or marketing) and the investment that you contribute (e.g. your own IPR), with the value that, also if the customer does not sign the full contract, (s)he will get- do not be shy about assessing the risk of a “freeloader”, and turn down presenting a proposal that is blatantly just a way to get free advice (I received plenty, from all around the world)
  8. line up the bits and pieces into something fitting the customer logic and perception this is just a communication packaging of the overall contract and relationship structure- you are basically preparing a script that will be played by the customer
  9. smooth the details and I mean real details- e.g. turning in the draft to lawyers from both sides (after the initial check in one of the first steps) to tune the legal issues- but without hijacking the contract
  10. seed the relationship more than once, after a negotiation was closed, the customer asked new ideas- or even, in few cases, my help in reviewing the contracts proposed by other suppliers: it is all (paid) activity, part of the relationship building activity that is a side-effect of the negotation (side-effect: the main aim must be signing the contract, not shine as a negotiator)


A critical issue in any negotiation is the presence of a unique communication channel (as it will be shown also in the “service” and “project” articles).

In some organizations, purchasing manages the negotiation with the support of the business side, in other organizations it is the other way around (or even you meet just one of the two).

My preference is to have somebody on the “process” side, i.e. purchasing, as (s)he will know what is feasible and will be able to reduce the time wasted in shuttling drafts (beside having a “wider” view), as well as somebody focused on “content”, to avoid a contract that, once signed, becomes meaningless at the kick-start meeting (it happened).

You can sometimes influence the choice on who will be at the other side of the table- but you can certainly decide who will be at your side of the table (if not- review why you are negotiating: I saw negotiations that were marketing activities for the negotiator, not for their customer).

If you have some “relationship middleman”, acknowledge their role, but then politely deflect their participation- unless they are the mediator (have a look on Wikipedia to GuanXi- years ago I even discussed with a Chinese contact in Paris localizing and integrating a CRM based on GuanXi for use with startups and SMEs contract negotiation and relationship management).

Why? Because they will not have the same commitment as you and the customer have, and they could just be a constant source of distraction and, potentially, dissent (to reinforce their own role as “saviour of the relationship”).

On your side of the table, try to have just one person covering the process, the negotiator, and one covering the business side (e.g. an industry-expert sales manager or pre-sales consultant), to avoid people starting chatting around the table or discussing alternatives.

I had that as well- how do they imagine that you can negotiate if they keep getting at the table with unheard of ideas is a mystery: no surprises- the negotiation is a role playing game; if you receive new information, you can always retire to review the new information.

I saw negotiations with larger teams on both sides- and it was interesting to pick up all the verbal and non-verbal signs from everyone: you can manage and control two people with clearly defined roles, but with a crowd… everybody intervenes and unwillingly discloses what was usually said in preliminary meetings about the negotiation’s “degrees of freedom” (i.e. your negotiating flexibility).

Having a smaller time with clearly defined boundaries makes the negotiations also more efficient, as you avoid that each point gets back the team to the drawing board.

It is a typical brinkmanship approach to push you with new information first presented, and then immediately used inside the discussion as a stepping stone, without giving you the time to do what the other party did- carefully select which information to present when.

If you want: in my experience, a successful negotiation develops more as a game of Go than Chess- you go for territorial concessions and wins, sometimes sacrificing individual minor points, not just for one big kill.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s