Speeding up Service Level Agreement Negotiations

by Stephen C. Sopko
Copyright ©2002 Stephen C. Sopko.

Negotiating a technical contract is nobody's idea of a good time. Few of us look forward to days spent in windowless conference rooms, discussing what might go wrong instead of actually making something happen. We watch, helplessly, while opposing lawyers spend an hour arguing over a comma. Then, we endure opposing engineers arguing over an obscure technical standard for the next hour. We all agree that negotiations take too long, but nobody seems to be able to figure out why.

Until now.

A few weeks ago, I discussed Service Level Agreements with a former boss. He was an expert on service contract negotiations and management until he retired in the 1990s. As we talked about my current role - leading an operations group negotiating contracts for a Fortune 50 technology company - I told him about the hassles of SLA negotiations and management. He asked, "SLAs? What are those? You mean performance clauses?" I explained that SLAs go beyond standard performance and level of effort clauses, seeking to nail down expectations and technological methods in advance of the contract.

"Sounds like the worst of both worlds," he said, "a contract written by technical people who don't want to write a contract."

Bingo. The more I thought about it, the more I realized that when he was teaching me how to negotiate major projects, we called the document a contract, not an SLA. A contract is the basic business agreement between two parties. Contracts must include an offer, acceptance and consideration. They often include limitations of liability and other legal principles designed to let both parties know what they are getting into.

A decade ago, the Service Level Agreement was simply a part of the contract that spelled out in some detail what would be achieved and how it would be measured. Increasing frustration with the pace of contract negotiations led technical experts to negotiate the SLA separately from the contract. In my experience, many technical experts no longer understand that without a solid contract, an SLA can be unenforceable in court and therefore meaningless.

To make matters worse, some technical SLAs come perilously close to directing how the vendor must execute. This can let the vendor off the hook if the project fails, as long as the vendor followed the customer's instructions in the SLA.

So, the lawyers insist on a proper contract, while technical professionals believe that every contract must be accompanied by an exhaustive SLA. The end result is that many modern projects require both a contract negotiated by lawyers, procurement and sales; along with an SLA negotiated by operations, engineering and other technical experts.

This duplication of effort is compounded by the fact that the resulting contracts/SLAs must be synchronized between legal and technical professionals who often disregard each other's priorities. If not, disagreements between the documents can make everyone's efforts meaningless. With all this, it is not so much that negotiations take too long; it is a wonder that they ever finish!

Danger Signs (If you are the seller…)

Who is driving the project versus who owns the negotiation? The wider the gap, the longer the negotiation.

• Identify whether the technical experts are truly committed to the project, or are simply going through the motions. The more excited the technical experts, the faster the resulting negotiation. If they aren't excited, it is up the vendor to find a way to make them excited. Don't confuse attendance with commitment.

• In the mid-1990s I participated in a major software integration negotiation from the buyer side. The CFO was an alumnus of a particular Big-5 accounting firm, and had already decided that this firm's technical services arm would lead the integration. He also negotiated the final price with his buddies at a golf course, leaving the 'nerds' to work out the details. The IT professionals felt left out of the decision process, and subconsciously resolved to make the SLA negotiation (the only part they really owned) as hard as possible. They asked for non-standard terms, punitive remedies for minor performance failures, and a host of extremely technical measurements that had little bearing on the business risk. The negotiations dragged on for months, and finally resulted in a stalemate halfway through the project.

Your Customer has minimal experience in service contracts, or, worse, has experience that left them with bad feelings toward service providers.

• The more experience the Customer has - the higher their degree of sophistication - generally the more direct the SLA negotiation. These Customers tend to value expedience, understand both the risks and the industry standards, and look for a compromise rather than a protracted bargaining session. The exception is a Customer with something to prove. Either they were burned on a recent project, or decided that they need to 'play hard' to meet an internal political requirement.

• When dealing with an experienced customer, leave 'spin' at the door - they will see it coming a mile away. Ask what their key success factors are, and ask if they would mind focusing discussions on those factors. They will be relieved, and see you more as a partner in the endeavor, rather than just a vendor.

• If their experience left them with a bad taste in their mouths, you cannot counter all of it at once. Your best bet is to build trust by demonstrating consistent excellence on several small projects. If you do not have time to build trust this way, offer substantial trust-building concessions that penalize you for failure, but also reward you for exceeding their expectations. Do this only where you know you can beat their expectations, and take no risks with execution. This willingness to be at risk with them - coupled with assurance that you can exceed their expectations - will build immediate confidence.
  

• With less experienced customers, their key concern is often less about the success of the project and more about fear of their own inexperience. I've seen negotiations bog down for days because a customer did not understand a key concept, refused to ask about it, and my engineers were too impatient to explain it to him. We were stuck until I asked a neutral third party to take the customer aside, and explain the concept privately. This allowed the customer to save face, and he allowed the negotiations to move forward. The lesson is, meet ignorance with patience. The old expression, "Win the argument, lose the sale" is especially important here.

A less sophisticated Customer states that they want the SLA to 'make them whole' after a failure. They can be very convincing, but seek something that cannot be offered.

• Years ago, I worked for a less experienced negotiator whose primary SLA goal was to be made whole after any substantial failure by the vendor. This sounded fair, until I realized that he wanted insurance, not service guarantees. Being 'made whole' after a failure is the responsibility of business continuity insurance. Looking to a vendor for this type of guarantee (barring negligence on the vendor's part) is unrealistic.
  

• To counter this, focus on SLA remedies as an attention-getter, something that will ensure the vendor's commitment to doing the job right. Characterized this way, along with the insurance vs. SLA argument, many customers will see the light and agree to more reasonable remedies.

Danger Signs (For the Buyer…)

You have a specific solution in mind, and want extensive customization from a Tier One company.

• Everyone wants to deal with the top tier, large companies. The sense of stability, professionalism, and deep pockets assures C-level executives of quality. This works for small to mid-sized customers only if the customer is willing to accept the vendor's off-the-shelf solution. The more customization the customer wants, the more the vendor has to adjust their standard SLA, the longer the negotiations will take.
  

• Address this by revisiting your requirements process, deciding whether an extensively customized solution is what you actually need. If it turns out that a top tier vendor's off-the-shelf solution can meet 90% of the business need, then it may be worth negotiating coverage of the last 10%. If you expect a tier one vendor to customize more than a few provisions, they might be willing to do it, but it will cost you.
  

• If the requirements analysis indicates a heavily customized solution - for example your competitive edge is at stake - consider buying from a financially stable, technically competent tier two company. These firms often have more incentive to build a custom solution for accounts the tier one vendors consider "small." Tier two firms have a greater flexibility, as they may not have invested in processes and infrastructure to support an off-the-shelf solution. This allows them more creativity in meeting your special requirements. Realize, however, that tier two firms also have less tolerance for financial risk - one serious mistake can ruin a financial quarter.

The vendor presents an SLA that is voluminous, confusing, and highly technical. The SLA measures, but does not assure.

• This is a favorite of telecommunication providers. If the SLA is only meaningful to other industry experts, there is usually a hidden reason. Most customers do not have the technical expertise to decipher such a document, and customer technical experts are often unwilling to admit they do not understand the arcane specifications. When pressed, a vendor with such an SLA will usually respond with arrogance, "Obviously, we are the experts in this field. This is clear because your 'experts' can't even understand our SLA."

• Another favorite of the complex SLA crowd is to measure excessively, bury the customer in performance data, and avoid linking the measurements to any real results. Mountains of data can reassure customers, but when there is a 'real-world' problem, the data always seems to either indicate that things are going just fine, or point away from the vendor.

• Address the complex, measurement-intensive SLA by focusing discussions on business needs. Tell the vendor you would be very happy with a two-page SLA that provides clear measurements of how the vendor's efforts meet the requirements and add value. Set a standard with the vendor that non-technical people (lawyers, operations, executives) must be able to read the SLA and grasp how it assures performance. If business needs mandate a technical SLA, then insist on a clear, well-written document with industry jargon defined. Ensure that measurements are included only as necessary to meet a business objective; and tie contract penalties to business failures instead of measurements. Finally, put technical experts on the negotiation team who will not be intimidated by admitting they cannot comprehend an overly technical SLA.

You believe that your company's people, processes and organization are the best in your industry. Any attempt to change 'how things have always been done' will be met with extreme resistance by internal stakeholders.

• This is a vendor's worst nightmare, but is on the buyer's danger list for a very simple reason. Internal constituencies will sink a project faster than any single external factor. Because of this, many vendors build escape clauses in their SLAs that reduce or remove their responsibility based on customer interference in their methods. Trying to negotiate these escape clauses away without addressing the internal political problem will result in a very protracted negotiation. Smart vendors will always walk away rather than assume the internal factions can be appeased after award.

• Address this by ensuring real buy-in from internal factions during the requirements process and afterwards. I witnessed a consultant-driven requirements process that did an excellent job of gaining enthusiastic support for a technical outsourcing project. When they completed the requirements document, the internal factions were so excited they threw a party for the consultants, who were then shown the door. After the consultants left, the requirement sat for three months awaiting funding. Once the funding materialized, a select technical and legal team spent six months negotiating the document. By the time the project mobilized, fully a year had passed since all the stakeholders were involved in developing the requirement. Executives had changed, business processes moved on, and key players forgot their enthusiasm for the project. It turned into a quagmire for the vendor, made worse by the fact that everyone's expectations of the project were set in stone by their memories of a year-old requirements process.

• Finally, you need to recognize that there is no team, technical infrastructure, business process or other competitive advantage that does not benefit from intense examination. The more you believe that something is sacrosanct, the more it must be questioned. The worst SLAs for buyers are the ones that must be crafted around a 'unique' requirement that turns out to be less special when exposed to the light of scrutiny.

Conclusion: Eight Points for a Fast Negotiation

• Buy from companies that want to sell what you want to buy. The more you try to force a vendor to accept your needs, the more protracted the negotiation and the higher the final cost.

• Sell to customers who want to buy what you want to sell. If a customer insists that you change something you cannot change, the negotiations are over. Be willing to walk away rather than sign up to something you cannot do.

• Never allow people to negotiate terms who will materially benefit from the transaction. The most frightening thing in the world is a salesperson negotiating terms; many will agree to significant risk to make commission on the sale. Many companies expect sales to move on after award of the contract, and unscrupulous sales people know that they will not be around to endure the consequences of a bad deal. Smart customers expect the salesperson to be at the periphery of discussions, not the center.

• Give experts a vote, not a veto. Lawyers, engineers, procurement and accountants are essential to the negotiation, but they are not the people who need the product or service being negotiated. Ensure that the experts retained are eloquent enough to convince the group of their opinion, and the negotiations will speed along. Give them a veto, and negotiations always stall.

• Give internal constituencies a veto, not a vote. If all internal constituencies who need the project have a vote, they will struggle endlessly to make the project meet only their needs regardless of cost. Once they buy-in to the requirement, keep them apprised of the negotiations, and schedule a final presentation after negotiations are complete. Present the final deal as an all-or-nothing proposition, and allow the internal entity to either approve the deal in its entirety, or veto it and stop the project.

• Negotiate the deal as a whole (contract and SLA) not separately. Any disagreement between contract and SLA presents a legal nightmare. Ensure that the same team negotiates both.

• Focus the SLA only on requirements that drive a business need, set penalties for failure to meet the business need. Focusing on business needs ensures that the final document will be meaningful, and a meaningful agreement usually results in a successful project.

• The fastest path to a deal: negotiate business needs first, then technology, then legal terms, and finally price. Once business needs are mutually understood, then quick agreement can be reached on technology and processes to meet those needs. After this, the lawyers can hash out the terms and conditions necessary to make the business needs and technology agreements enforceable. Finally, once all of the needs, technologies, terms and conditions are agreed, both parties are aware of their risks enough to negotiate a price. At this final stage, changes to earlier stages can be made to either offset risk or reduce cost.

Stephen Sopko is responsible for over $4.3 billion worth of contracts for a Fortune 50 IT manufacturer. His background includes 10 years as a federal contracting officer, and 6 years as an executive and manager in start-ups and Fortune 500 corporations.

home