Category Archives: contract management

Do Your Contracts Enhance Trust or Destroy Trust?

A recent article in the Harvard Business Review notes that good contracts are designed to reinforce trust and reduce risk but that there can be a fine line between a good contract and a bad contract which destroys trust and, ultimately, increases risk. A contract that is too detailed or rigid, or one that sends mixed signals, can exacerbate the problems it was intended to preclude as it can restrict creativity and even prevent the display of good intentions.

For example, if the contract specifies a rigid resolution process that requires that all issue reports need to be reviewed by a team before being classified as either errors or enhancement requests, at which point they will be placed a queue for resolution, and the bug is actually preventing the client from getting work done, instead of insuring that the client’s requests are addressed in a fair and equitable manner, the contract is preventing development from making what might be a quick fix. Instead of engendering goodwill by attempting to insure every request from a client is considered, you’ve created ire by preventing a developer from getting a client running again quickly.

The reality is that most negotiators want to overestimate the level of certainty and underestimate the likelihood of future divergences from the situation they perceive during negotiations. As a result, fewer contingencies are included and terms are finalized sooner than they should be. A good contract defines a good dispute resolution process and leaves room for renegotiation later if circumstances change. Something to think about before being too hasty to dot every i and cross every t in your next negotiation.

Tired of Yo-Yo Contracts? Fix the Price with an Indexed-Based Model

When markets yo-yo, so do buyers and sellers … and they waste time, and money, doing so. When prices fall, buyers scramble to cut new contracts to obtain better prices and mythical “savings”*. When prices rise, suppliers scramble to exit contracts to get better prices from other buyers. And when prices yo-yo, it’s a never-ending renegotiation dance that does nothing but waste time, and money, especially when there’s an easy way to lock in a contract for the long term that allows both parties to win. It’s called the Price Index(ed) Contract, and in this post I’ll explain how you can lock in a contract that will protect both parties and allow you to avoid the renegotiation dance … which will allow you to focus on more categories and new, and better, cost savings opportunities.

The first thing to do is to build a should-cost model that captures all of the major price components (> 5%, if not > 10%) using current prices, drawn from an index. We’ll use a (hypothetical but representative) cost breakdown for a 30kVA power transformer, since we all need power, as the foundation for our example.

 

Cost Amount Percentage
Steel 1055 34%
Labor&Overhead 620 20%
Misc 560 18%
Copper 530 17%
Oil 215 7%
Transportation 125 4%
3105 100%

 

This tells us that our primary cost components are steel, labor, and copper and that oil would have to to fluctuate 5% to have the same impact as a 2% fluctuation in copper and 10% to have the same impact as a 2% fluctuation in steel. This also says that if our threshold for negotiating a contract is a minimum cost reduction of 5%, that oil would have to fluctuate 70% for us to even consider a renegotiation. Given that rampant runs, like the one which we just experienced where oil tripled and fell back to the baseline in less than two years, historically only happen every few decades, and that labor costs tend to increase rather predictably with inflation, it also tells us that we should only be concerned with steel and copper costs.

There are market based indices for both steel and copper, the CRU is one example of the former and the New York Futures Market is one example of the latter. At least one of them will, on average, correlate to the prices that your supplier consistently plays for steel just like at least one of them will, on average, correlate to the prices that your supplier consistently pays for copper (which depend on their contracts, leverage, and the market(s) they buy from). You just have to agree on one.

Then, you can tie your contracts to the index and word them to automatically adjust prices on a monthly (or quarterly) basis using the impact of market price fluctuations on the should cost model. Since steel accounts for roughly 34% of the cost, if you agree to cost a increase of 1% for every 3% increase in steel cost, you won’t have to worry about your supplier having to choose between reneging on your contract or financial ruin in a bull market and if your supplier agrees to a cost decrease of 1% for every 3% reduction in steel cost, he won’t have to worry about you having to choose between finding cheaper sources of supply or risking financial ruin due to your inability to compete with (unrealistically) high costs. Similarly, if you agree to a cost increase of 1% for every 6% increase in copper price and your supplier agrees to a cost decrease of 1% for every 6% decrease, neither party loses — and more importantly, both parties win. In bull markets, your supplier gets to pass on the raw material cost increase — and only the raw material cost increase (as you both know the cost, no ridiculous mark-ups), and in down markets, you reap the savings without having to go through a long, time-consuming, wasteful renegotiation.

This works for any category you can think of, allowing you to lock in 1, 2, 3, and even 5 year contracts (on non-strategic categories) without having to worry about lost opportunities or overpayments. The only thing you have to do is check the indexes once a month (or quarter) on the date you both agree to “reset” the prices for the next month (or quarter) to make sure your supplier is holding up their end of the bargain. And you can even use this model to take into account financial costs, such as foreign exchange rate assumptions (if raw materials or components are being bought in a foreign currency) or finance assumptions (if part of the product or transportation cost needs to be financed). So build a should cost model and get that yo-yo off your finger.

* There’s no such thing as “savings”. “Savings” is just money you shouldn’t have spent in the first place. (And that is why “cost avoidance” is more important than “cost reduction”, despite the refusal of many old-school diehards to recognize that fact.

Optimizing Your Procurement Technology Investments

The Sourcing Interests Group recently ran an interesting article on “optimizing your procurement technology investments in 2009”. Although it had some good suggestions, my top five suggestions would be the following:

  1. Get Visibility Into Your Spend (Spend Analysis)
    If you don’t know how much you’re spending on each category, sub-category, product, and service, who you’re spending it on, in what amount, by unit, you need to get this visibility. Get a good spend analysis solution and dive in!
  2. Take Your Strategic Sourcing up a Notch (with e-Sourcing)
    Start with the most attractive savings opportunities that were outlined in step 1. This is your best bet to negotiate big savings in this downturn.
  3. Focus on Contract Compliance (adopt Contract Management)
    You need to enforce hard-won savings by insuring that internal staff and suppliers are compliant with contractual agreements.
  4. Implement e-Procurement
    Done right, this will make it easy for your buyers to buy on contract.
  5. Get a Grip on Global Trade (adopt Trade Visibility solutions)
    Chances are your global sourcing endeavors are needlessly costing you more than you think! As per my recent Illumination on why you need trade visibility, you’re probably paying more than you need to on duty, using costly inefficient processes, paying unnecessary document preparation costs, and making costly errors that are costing you million of dollars a year.

Fine-Tune Your RFPs for Streamlined Performance (Software Acquisition Insider Tips VII)

A recent article over on Supply Management . com on “going faster” pointed out many of the problems with RFXs that cause unnecessary process delays. Fixing these problems will enable your RFX process, which you now know how to construct in an unbiased fashion, to flow smoother and faster.

  1. Poor Scope
    The scope is not clearly defined at the start of many RFP processes. “A solution to automate our purchasing” is extremely vague as is “50,000 boxes”, which a quick trip to cBoxBid will quickly point out. (Dimensions? Style? Weight/Flute? Glue Tab? Printing? Color? etc.) The scope needs to cleary define what is required (automation of purchase order creation, invoice collection, and e-payments or 12″*12″*8″ boxes that can hold at least 45 lbs) and the desired outcomes (automated tactical processes with m-way matching and manual review only required on discrepancies and purchases over administrator defined thresholds or 5,000 boxes per shipment with 21 days notice).
  2. Lack of a Performance Regime
    The long-term success of a major contract will depend on a mix of “hard contractual” and “soft behavioural” factors. It is imperative to define success via a comprehensive performance regime with a simple hierarchy of performance measures and targets, and a mechanism for rewarding good service and deterring underperformance.
  3. No Team Empowerment
    Like every other sourcing and procurement activity, a successful RFX (process) requires a dedicated and fully supported team. A core team, authorized to make the necessary decisions, is required throughout the process and beyond to ensure consistency and clarity with the bidders.
  4. The Contract is an Afterthought
    The RFX should be presented in a format that matches the product or service being requested and should fully explain the selection process, the evaluation criteria, the rules of engagement, the delivery schedule, and the terms and conditions. In other words, the contract (template), which should clearly specify what is and is not negotiable, should be drafted up front and presented to all participants. Otherwise, you might work through a long, laborious RFX process only to find out that the winning bidder(s) can not, or will not, agree to your terms and have to go back to the drawing board.
  5. The Process is Not Managed
    The largest risk in any RFX process is a misunderstanding, and the sad thing is that this is very likely if sufficient information is not made available to the bidders and the process is not managed. It’s important to manage the process and communicate with the bidders at each step to make sure they have received all of the materials, understand all of the requirements, and have all of the information they need to craft their responses. The process should include regular briefings, review meetings, and question and answer sessions to insure that it flows smoothly.

SaaS Contractual Considerations: Part II

Despite the claims to the contrary from the monolithic on-premise players who are threatened by the new platform and all of the advantages it has to offer, SaaS is gaining momentum. The best evidence I have to offer is the rate at which analysts and bloggers, including yours truly, are getting inquiries into how to evaluate these offerings from a functional and TCO perspective and how to construct the contract. And it’s not just buyers who want to know what needs to be in the contract to protect their investment. Providers also want to know what clauses they should be including to protect themselves as well.

As I am not a lawyer, I cannot claim to be an expert on contract construction of any kind, but I can claim to be very familiar with IT contracts (as someone who has always handled his own and been involved in their construction and review at a number of companies) and to have considerable knowledge with regards to issues that need to be addressed on both sides of the table. Thus, I give you the doctor‘s top issues for consideration when negotiating your next SaaS contract in addition to the standard issues of term, fees, liability, representations, warranties, confidentiality, insurance, indemnity, rights, relationship, dispute resolution, publicity, and government law that your lawyers will remind you of in every contract drafting. Today, we’ll focus on the supplier:

For the Supplier:

  • We’re Not Responsible for Your Network
    You are responsible for your software and network, and not your client’s software and network. If your client’s ISP goes dead, not your problem. If your client’s router starts acting flakey and randomly blocking required ports, not your problem. Your support requirements cease the minute you are able to demonstrate the problem is not on your network.
  • We’re Not Responsible for Your Systems
    As a provider you are responsible for your software and your network, not your client’s software and network. As long as you provide the client with a complete list of compatible software products and supported versions, and the client agrees to it, you’re under no obligation to support the client should they choose to use other products or upgrade to non-supported versions before you have certified that such products are compatible with your system. I.E. if IT upgrades all the browsers before you certify them as compatible, and your system doesn’t work, not your problem if the client agrees in the contract to only use, and expect support on, pre-agreed browsers and supported versions thereof. Of course, in fairness, you should expect to have to support new versions within a certain time-window and agree to do so within a realistic time-window.
  • We’re Only Responsible for the Security of Data in our Systems
    You’re required to follow industry standard best practices around data security and insure that all confidential and personal information on your systems is appropriately encrypted to the level of security agreed upon in the contract. However, you’re not responsible for what your client does with that data once they extract it from your systems. If they decide to cut and paste out of a secure browser session into an unsecure notepad file on a hacked PC, you cannot control that and have no responsibility for the consequences of such action.
  • We’re Not Responsible for Disasters Beyond our Control
    You’re responsible for your software, systems, and data centers to the extent that you have control. Your Force Majeure clause says that you are not liable for damages if both of your power providers go black or if both of your internet connections get severed because of a natural disaster or other government or terrorist action beyond your control. That being said, if your providers stay dark for more than a short period of time, it’s your responsibility to transition to a backup facility or enable your client to set up a temporary instance of your application in their facility as per the terms that any reasonable buyer should be expected to insist on in the SLA.
  • Standard Rate for Services Above and Beyond our Standard Offering
    You’re responsible for support, maintenance, upgrades and other services you agree to — and that’s it. Although you are happy to go above-and-beyond your service requirements, make it clear that you do not do custom work for free and that any custom tasks or services will be billed at a standard hourly or daily rate on the monthly invoice. Otherwise, the buyer might say “we thought that was free” and put you in a pickle if you hired additional resources to support the buyer above-and-beyond the agreed upon service levels.

Be sure to check out the Master “Software as a Service” Managed Services Agreement in the Procurement-Based Contract Templates, Version 2, that is made freely available to you by Stephen Guth of The Vendor Management Office blog.