Dear Big Co. Here’s Why Your Contracts Suck …

… and why no one wants to sign them, yet alone even read them!

And since all contracts should be written in plain English (or, if between two parties whose native language is Elbonian, in plain Elbonian, for e.g.), at a senior high school reading comprehension level, we are going to write this post in plain English too.

They are too long. No one wants to read 100 pages of your lawyer’s hyperbole rhetoric that is, in common terms, the literary equivalent of a steaming pile of cow dung.

You read that right. No one wants to read 100 pages of your lawyer’s hyperbole rhetoric that is, in common terms, the literary equivalent of a steaming pile of cow dung.

Furthermore, at least 90 pages of this is guaranteed to be completely unnecessary (and you should feel ashamed at the money you wasted paying your high powered corporate lawyer to write it in the first place).

Let’s go back to the purpose of a contract.

To clearly specify

  • the obligations between two parties,
  • the benefits to both parties from meeting their respective obligations, and
  • the recourse available to one party if the party defaults on the obligations of the contract.

In plain English, even English written by the bard himself, how many pages does that take? Even in the most sophisticated of transactions with a list of obligations by both parties, probably not more than a few pages. (Now, if you are contracting for the construction of an office building, you might need hundreds of pages of addendums on architectural, structural, municipal, etc. requirements, but that’s not the heart of the contract. This can be clearly captured in a sentence that states party X agrees to build the structure required by party Y, as clearly detailed in appendices A through T that detail obligations 1 through 20 respectively, do so for a fixed fee of Y M, and delivery by due date, with penalties accruing at the rate of Z00 K per month. Simple, eh?)

After you’ve specified the mutual obligations, there are only three other requirements for a contract:

  1. Requirements of your Insurance Company
    If your insurance requires limitations of liability, certifications, etc. to explicitly be included for it to remain in effect, you include these requirements, and only these requirements, and only to the extent required.
  2. Requirements of the jurisdiction in which you are operating your business
    If you are doing business in the US, and you are buying technology that could possibly fall under ITAR (for example) if certain requirements are not adhered to, then it must be contractually clear that the products will be designed to adhere to those requirements. (Encryption will not exceed a certain level, etc.) Furthermore, if there are regulations against human trafficking in the supply chain, taking measures to insure denied parties do not receive financial payments, etc. that must be adhered to, then these are included as well.
  3. Requirements of any jurisdictions in which you are subject to as part of the transaction
    If the jurisdiction of the other party can imposed requirements on you, or if you plan to sell the products or services bought in a third jurisdiction, you need to include any requirements imposed by those jurisdictions.

However, this does not mean you include pages and pages of detailed requirements and regulations, that are well defined in the appropriate laws and statutes and regulations you are bound to, merely that you reference those regulations and require the other party to adhere to them. This usually requires only a few sentences per regulation, max. Not paragraphs and definitely NOT pages.

That’s it. Nothing else. And I cannot emphasize enough that you don’t include something else just because your lawyer decides there is a minute 1 in 1,000,000 risk that something could go wrong and someone with a better funded legal team could possibly find an innovative way to wiggle out of a contract that didn’t cover the obscure case of a worker tripping and skimming his knee because he stepped on a snail on the way to your worksite. Over funded legal teams under the control of people with more money than brains can always come up with harebrained arguments and ridiculous legal challenges — but how often does it really happen? Especially between two parties who were open and honest in negotiations and go into the contract fully intending to fulfill it? And is it really worth spending tens of thousands (or more) of legal time on an average contract which is usually a small fraction of organizational spend? (If an organization has 10,000 contracts and it’s revenue is less than 10 Billion, the average contract value would appear to be one million, but give that there will be a few large contracts with key suppliers that leverage volume, you’ll have a few dozen contracts in the tens or hundreds of millions and an “average” contract in the tens or hundreds of thousands.)

Remember, your lawyer’s job isn’t to tell you what to do. Your lawyer’s job is to listen to what you want to do, advise you of the risks, and then do whatever you tell him to do, which definitely includes writing short, easy to understand, contracts that people will actually sign. At the end of the day, you need to do your business. Contracts should enable that, not get in the way.

Sourcing the Day After Tomorrow Part XI

In this series we are doing a deep dive into the sourcing process today, and, in particular discussing what is involved, what is typically done (manually), and whether or not it should be that way. We have already completed our initial discussion of the initial project request review phase, the follow up needs assessment, the strategy selection phase, and the communication phase. Now we are in the analysis step. At first glance, it looks like this is more strategic and human-driven than prime for tactical automation, but we have been fooled before (and won’t get fooled again).

We are discussing the analysis step, which has the following sub-steps that have to be completed every time (and not just sometimes):

  • Market Pricing Data
  • Historical and Projected Spend
  • Cross-Category Materials Spend
  • TCO / TLC (Total Cost of Ownership, Total Lifecycle Costs)

Let’s start with market pricing data. While humans need to review and verify the data for accuracy and completeness, they don’t need to manually collect it. Consumer pricing can easily be collected from crawlers and punch-outs, many BPOs/GPOs have APIs and data feeds or at least easily parsed CSV files, and pricing from government contracts can usually be downloaded from government sites and automatically parsed. As a result, most of the market pricing data collection effort is easily automated.

When it comes to historical and projected spend, this can be easily be pulled from a good spend analysis system once all the data has been cleansed, categorized and enriched. A few rules get the relevant spend, the related spend, and the application of a few algorithms can easily automate the calculation of projected spend under standard assumptions.

When it comes to cross-category materials spend, if the organization’s ERP contains bill of materials (and approximate usage of a raw material in the production of a product or service), and if the spend analysis system is configured to support this level of detail, then the cross-category materials spend can be pulled out of the spend analysis system in an automated fashion and matched to the current and projected spend. All a human needs to do is review and verify the data.

Finally, in the TCO/TLC phase, most of the relevant costs factors can be automatically identified by a modern spend analysis system that can match invoices to goods and services and identify the associated costs as well as through a contract analytics systems that can analyze past contracts and pull out the “hidden” costs that the supplier passes on to the buyer (in margins or lump-sum fees). Plus, semantic analysis of product descriptions can allow other direct and indirect costs to be identified, and all of these factors can be compiled to create a should-cost model, with certain costs (such as transportation, import/export fees, taxes, etc.) automatically pulled from market data and other costs estimated using prior costs and estimated costs on related categories. A human has to do the final analysis and sanity check, but so much of the tactical drudge work of analysis can be automated these days that it’s almost cognitive.

In other words, the more we explore the sourcing process, the more we find out how truly tactical the majority of it is. But we’re not done, so in our next four parts we will explore the last two phases of negotiation and contract.

Sourcing the Day After Tomorrow Part X

In Part I we recapped Sourcing today, in Part II we did a deep dive into the key requirements of the review step as it is today, and then in Part III we did a deeper dive where we explained that while some steps were critical for a sourcing professional to undertake, others, while necessary, were a complete waste of skilled talent time as the majority of the tasks could be automated. Then in Part IV we began our deep dive into the needs assessment phase which we completed in Part V. This was followed by a deep dive into strategy selection in Parts VI and Part VII and the communication step in Parts VIII and IX. And upon review of these steps, we’re still at the point where some tasks have to be done by humans whereas others can be mostly automated. We’re starting to suspect this is true across the entire sourcing cycle, but we can’t be sure until we complete our analysis, can we?

In the next step, the analysis step, we have the following key sub-steps that have to be completed every time (not just sometimes):

  • Market Pricing Data
  • Historical and Projected Spend
  • Cross-Category Materials Spend
  • TCO / TLC (Total Cost of Ownership, Total Lifecycle Costs)

In the market pricing step, you collect as much information as you can about pricing for the goods or services you are looking to acquire to be as informed before negotiations as you can be. This could require collecting consumer pricing from retailers, pricing available from GPOs/BPOs, pricing from government contracts (that are public data), import / export manifests (to determine volumes and supply/market dynamics), and pricing from similar product/services on past contracts. It could also involve collecting competitive intelligence through analyst reports, buying collectives, and other avenues.

In the historical and projected spend phase, the organization does deep analysis of historical spend and volumes across the product and services lines, similar product and services lines, and market dynamics. It then pieces all of this together to form projected trends that look at current trends modified with projected demand shifts within company product and services lines and expected uptakes or product line abandonments based on current market dynamics. It collects as many pieces of data that are readily available to try and determine if market shifts are seasonal, responsive to price changes, reactive to new product introductions, or undetermined factors.

In the cross-category “materials” spend phase, the organization makes an effort to identify the the primary components of the spend and how they should influence the spend dynamics of the product or service being acquired. For example, if it’s a metal product where steel is a primary component, they will attempt to identify how the pricing is shifting in other categories where steel is a primary component and compare that to market price shifts. If it’s a service, they will look if the primary costs are related just to talent, to organizational support, or even expenses (such as excessive travel requirements) and compare that to market costs across different divisions of the company. (E.g. extra
IT support is IT support whether contracted by Procurement or IT)

Finally, in the TCO phase, the organization will work hard to identify all the other direct and consequential indirect costs associated with the acquisition. Taxes (and whether or not they are reclaimable and the costs of reclamation if they are), import/export duties, intermittent storage fees, transportation fees, typical loss fees (due to spoilage, waste from mandatory tests, etc.), etc. will be identified and factored in as direct costs. In addition, potential indirect costs such as additional testing, expected loss during local transport, alteration costs for implementation, loss of co-marketing support, etc. will be factored in.

This sounds largely human driven, but, as we’ve discussed during previous steps, sometimes what sounds human driven isn’t. But this is a subject we will explore in Part XI!

Sourcing the Day After Tomorrow Part IX

In this series we are doing a deep dive into the sourcing process today, and, in particular discussing what is involved, what is typically done (manually), and whether or not it should be that way. We have already completed our initial discussion of the initial project request review phase, the follow up needs assessment, and the strategy selection phase and are in the communication (identification) step. At first glance, it looks like this is an entirely strategic human-driven step with little option for tactical automation, but is this the case?

As per our last post, the communication step of the typical sourcing process, we have the following key sub-steps that typically have to be completed:

  • Standard Protocols
  • Supplier e-Communication Capability
  • Level of Detail Required
  • Response timeframes

Let’s start with the standard protocols. At some point a human has to establish the standard (organizational) protocols, but how much do they change from event to event for a product or service or category or across products and services within a category (or across similar categories)? Not much. There’s no reason that once an event is created a system can’t find the closest event or category that’s ever been done, extract the communications protocol that was used, present it to the buyer, allow the buyer to accept all, or part, and if only parts are accepted, find and recommend the next best parts, and then allow the user to edit the closest parts to make it all fit. A great platform will make it extremely quick and easy to create a standard communication protocol and framework, and even quicker to set up automation using templates, timers, alerts, and other capabilities of modern Source-to-Pay platforms.

When it comes to supplier e-Communication capability, once the buyer has an e-mail, the platform can send out the surveys to those suppliers that are new and, more importantly, suck in profiles from other events from suppliers that have recently responded. And if the response is over a year old, automatically resend it to the supplier for verification. There’s no reason a human has to do very much at all. This is a step primed for platform automation.

The level of detail required step, like the standard protocol step, is another step where a human has to make an initial decision at the organization, category, or product level, but once that decision is made, and captured, there’s no reason a human ever has to make that decision again (unless an event happens that indicates the decision no longer fits). The system should be able to extract the right guidelines and templates to help the humans through the proper supplier communication protocols and responses and allow the buyers to focus on the strategy, not the minutia.

Finally, with respect to response timeframes, the system can query organizational guidelines, decisions from previous events, and typical average response times and present the buyer with suggested response timeframes. It also enables the buyer to alter any suggestions quickly and easily so that the buyer can produce all the internal guidelines and disseminate them in a quick and easy fashion and spend more time on the preceding strategy step and the following analysis step.

In other words, we again see that, without proper system support, a buyer will waste much of their time on tactical processes, non-strategic data collection, and making the same tactical decisions over and over again and Sourcing really has to change.

Sourcing the Day After Tomorrow Part VIII

In Part I we recapped Sourcing today, in Part II we did a deep dive into the key requirements of the review step as it is today, and then in Part III we did a deeper dive where we explained that while some steps were critical for a sourcing professional to undertake, others, while necessary, were a complete waste of skilled talent time as the majority of the tasks could be automated. Then in Part IV we began our deep dive into the needs assessment phase which we completed in Part V. This was followed by a deep dive into strategy selection in Parts VI and Part VII. And upon review of these two steps, we’re still at the point where some tasks have to be done by humans whereas others can be mostly automated. But is this true across the entire sourcing cycle? Let’s dive into the communication step.

In the communication step of the typical sourcing process, we have the following key sub-steps that typically have to be completed:

  • Standard Protocols
  • Supplier e-Communication Capability
  • Level of Detail Required
  • Response timeframes

The communication step starts with the identification of standard protocols that will be followed throughout the rest of the process in all communications with suppliers, whether initiated by the buyer or the supplier. Once the protocols are identified, they need to be implemented in all mechanisms that will be used to communicate to suppliers so that they can be enforced to the extent possible by the systems that will be used. For example, if notifications will be sent out within 72 hours of receiving a submission or making a decision, the platform can either automate notifications or automate alerts.

The supplier e-communication capability step seeks to identify the suppliers ability to use e-communication, and to use it effectively. This will require reach out to suppliers to identify what they have in terms of technical skills, internet bandwidth, and Supply Chain e-Commerce systems (can they accept EDI, XML, etc.) and their ability to support modern requirements such as digital signatures and block chain.

The level of detail requirements step determines what level of detail will be required in each communication that will be sent out as part of the process. For example, in the RFI step, you may need to send out details on filling out the RFI, requirements for completeness, supported file formats for certificates, etc. In the award step, you might detail what will, and will not, be included in a (lack of) award notification. And so on.

In the response timeframes step, the buyer determines what the response timeframes will be not just for pre-defined step, but for responding to supplier questions and unsolicited supplier communications. And for dealing with unexpected communications, such as failure during an auction, suppliers not responding on time, and so on.

All this sounds like it’s all human driven, but is it? And it sounds like it’s pretty quick and simple compared to the last few steps, but is it? I guess that’s what Part IX is for!