Category Archives: contract management

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.

SaaS Contractual Considerations: Part I

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 buyer:

For the Buyer:

  • Data Export, Backup, & Security
    It’s your data and you should have full access to it 100% of the time and the ability to extract some of it or all of it on a whim with little or no notice to a standard, open format such as CSV, EDI, or XML. Of course, if the provider is hosting your entire ERP system and you have Gigabytes of data, expect to pay a bandwidth usage fee if you plan to do this regularly, or a service fee if you require the provider to back it up to encrypted DVDs or Tape and courier the data to you. Similarly, it’s your data and you have every right to expect it to be secure and available no matter what. Insure that the provider is required to do complete backups at least daily, incremental backups at least hourly, and required to store a copy of the encrypted daily backups in an off-site location.
  • System Availability & Up-Time
    One of the attractions of SaaS is the 24/7 uptime that your average company IT shop, that works 9 to 5 in one time zone, can’t deliver. Make sure the system has a guaranteed up-time of 99.999% when you need it (e.g. between 8 am PST and 8 pm GMT if your users are predominantly in North America or Europe) and that you have at least 99.5% uptime the rest of the time, with scheduled maintenance only occurring in agreed upon time windows with adequate notice.
  • Pay For Use
    The beauty of SaaS is the scalability it offers you and the ability to add or subtract users as needed. Make sure you’re SaaS agreement only charges you for the number of users with active accounts (subject to any minimum number of seats you might have agreed to) on a monthly basis.
  • Guaranteed Response Time
    There’s no perfect software system and something will inevitably go wrong with on-demand just like something inevitably went wrong with your current on-premise system. Make sure that the provider agrees to start investigating all outages immediately during agreed upon normal operating hours for your business and within 30 to 60 minutes otherwise. Make sure they are required to get back to you with progress within a maximum timeframe of 60 minutes and to report on progress on an agreed upon schedule.
  • Escrow & Guaranteed Availability
    You generally select an enterprise system with the intent of using it for at least the mid-term, if not the long term, and if a system works well for you, the last thing you want to happen is for the provider to disappear (either due to financial failure or M&A) and take its system with it. Thus, it’s important to take precautions that will insure that, no matter what, you will have continue access to the system for as long as you so desire. The way to do this is to (1) insist on escrow and immediate access to the updated source code and related documentation which is to include required system architectural designs, complete installation instructions, and maintenance and support manuals that are kept up to date on every release and (2) forced support for a minimum period of time on material change of ownership, including the option to acquire the system from escrow at an agreed upon perpetual (annual) license cost at the end of the the minimum support period if the acquiring company no longer wishes to support the system.

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.

A Great Guide to Outsourcing Risk Management, Part III

In Part I we we discussed the starting point of your outsourcing project and how you go about selecting service providers to issue RFPs to and in Part II we discussed proposal evaluation. Today we will discuss the contract, and the dispute resolution process in particular, and remind you to check out the full series on outsourcing risk management by Alsbridge, as printed by SourcingMag.com, that this series is partially based on.

So What Needs to Be In the Contract?

Lots and lots of legalese, of course, and I highly recommend you check out Stephen’s Guth Vendor Management Office Blog and the books and downloads he has indexed on his site (including The Contract Negotiation Handbook and Implementing a Vendor Management Office) before you start. That being said, there are two critical sections that must be in every outsourcing contract, and that must be carefully thought out and specified in detail before the contract is signed if you really want to alleviate potential risks, and they are dispute resolution and service level agreements.

So What Do You Need With Respect to Dispute Resolution?

Remember, if there is a disagreement between two parties, the time to figure out how to discuss and resolve it equitably is not in the midst of the disagreement. That’s why the rules for boxing matches are set in advance rather than discussed after one fighter has already tried to bite the other’s ear off. Making the process as defined and clinical as possible will remove tension from disagreements, especially when things must be escalated and your counterpart is angling for your ear. Be sure that each of the following questions are answered in your agreement before the agreement is signed.

  • What is the process for raising an issue?
    This must be spelled out, or the other party can claim that they were not aware of an issue, and hence under no obligation to take any action.
  • How long does each side get to investigate and formulate a reply?
    The party being notified of an issue must have a set timeframe in which they have to formulate a reply, otherwise, they can stall indefinitely with “we’re looking into it”.
  • If the issue is not resolved, who meets?
    The project managers? Subject matter experts? Mangers? Executives?
  • When?
    The meetings to resolve issues, and resulting disputes, can be ad-hoc or regularly scheduled, but there must be a maximum timeframe that can elapse without a meeting being when there is an issue to resolve or there is nothing to prevent one party from stalling the other indefinitely.
  • Does the timeline vary based on issue size?
    If one party discovers the issue to be larger than originally thought, is an additional fixed time allotted for further investigation or resolution?
  • When does an issue become a dispute?
    After an unsuccessful meeting? After 7 days without resolution? This must be clearly defined.
  • What clear authority does each party have to negotiate?
    This must be clearly defined so that the right people are at the table for issue, and dispute, resolution meetings. Otherwise, the other party can claim that their representative had no authority to negotiate on their behalf and stall a negotiation indefinitely. The contract should also stipulate what authority project managers have to resolve issues and disputes. For example, sometimes a few extra hours of work on behalf of one party or the other, even if they have to be off-the-record, can go a long way to resolving problems and building a rapport that is invaluable to team success. For example, if a project was supposed to take eight weeks, but at the end of eight weeks, three days of work is left, is it really worth a dispute? Or can the project managers for each party decide to just “split the difference” to get it done and move on.
  • How long do the authorities have to get to the table?
    If a dispute arises, how long do parties with the authority to resolve it have to get to the table.
  • If no agreement is reached, when can the issue be escalated?
    There’s always a good chance that a dispute will arise that cannot resolved amicably between the parties at the table in a reasonable timeframe, so it must be crystal clear when a party can request that the problem be escalated within their counterpart’s organization.
  • What triggers arbitration or legal action?
    Although everyone hopes it won’t happen, some disputes will not be resolved even when the CEOs make it to the table. Therefore, the agreement must clearly spell out when a party can request arbitration or resort to legal action if it was clearly damaged by an action, or inaction, of the other party.

The next post in the series will discuss service level agreements.