Truckloads of Money

I’m not a lawyer, and nothing here is intended as legal advice or should be seen as a replacement for working closely with your corporate counsel. Having a good working relationship with your legal team helps streamline the process on your side, which is also important. This is intended as a high level overview and a practical guide to using the SOW process to make success predictable and repeatable.

When companies form a business relationship related to technology, there is typically a master agreement such as a Master Services Agreement, though it might also be called a Master Licensing Agreement, a Purchase Agreement, or something else. The master agreement describes the relationship between the two companies, the guidelines for subsequent business engagements, ownership and other rights to any work products, liability, and conflict resolution.  What master agreements don’t cover is time, money, and any subsequent deliverables.  Those get broken out separately in attachments typically called SOWs, or Statements of Work. It’s important to ensure that you have an agreement in place that supports the attachment of SOWs if you plan to get paid for additional work such as customization or integration.

Statements of Work are a part of a contract that defines work to be performed and money or other considerations which will be received in exchange for performing that work.  SOWs are typically attached to a master agreement. One can think of the master agreement as a bridge between the two companies and SOWs as trucks that cross the bridge carrying products and services in one direction and returning with truckloads of money in the other direction.

Large companies may have a preferred format for SOWs, though that has not been my experience.  They invest in ensuring that the Agreement that governs SOWs protects their interests, but it is typically left to the individual executives on either side to agree how to format their SOWs based on the specific nature of the business relationship.  It’s worth noting that SOWs can potentially override defaults within the governing Agreement, where it allows them to do so, but that doing so is rarely a good idea because it requires additional scrutiny that can cause delays and even generate mistrust. Far better to follow the rules of the road and keep the SOW “trucks” moving.

What is in a SOW?  Ideally a SOW contains the following elements:

• Scope: A human readable overview of the scope covered by the SOW.  This allows anyone who is reviewing the SOW to quickly identify what it pertains to.  After all, the goal is to have many SOW “trucks” moving back and forth across the Agreement bridge.  This overview should make it easy to understand what this SOW covers.

• Deliverables: A list of the specific work products that must be delivered to the customer in order to satisfy the terms of this SOW so that the customer sends back a truck filled with cash.

• Project Schedule: The dates when work is expected to start and when the work product is expected to be completed and delivered.

• Invoice Schedule: A declaration of fees with an invoice schedule. The fees state how much cash the customer is expected to pay and the invoice schedule defines when the customer will be billed.

• For shorter work efforts, invoicing may be tied to specific deliverables.

• For longer work efforts, an invoice may be submitted at kickoff, with additional invoices at intermediate milestones to cover expenses that will be accrued during the project.

• For ongoing staffing projects, invoicing may be tied to calendar dates.  For example, if the customer was paying for a dedicated Project Manager across a variety of projects, there might be one SOW specifically covering that role with monthly invoicing.  The deliverable in that case might be a report describing the work performed by the PM during that period.

A Staffing Matrix may also be required, particularly on SOWs related to customer specific projects, whether it is building software exclusively for a customer or customizing and integrating your existing product for a customer.  Ideally the staffing matrix includes roles, responsibilities, and allocation (percentage of time, number of weeks) for each resource using the role of the resource in place of the name of a specific person.  In some cases, the customer may require the names of resources deemed critical to the project.

The SOW likely contains other sections such as Defined Terms, Assumptions, Acceptance Criteria, and Change Management, but most of those sections become “boilerplate” over time, meaning they don’t change from one SOW to another, allowing you and the customer to focus on the items above, which are more important to a specific work effort.  The goal should be to use transparency to build trust so that many SOW trucks can move back and forth over the bridge.

Tips and Techniques:

• Provide a human readable summary so that anyone who picks up the SOW can readily understand what it pertains to, what work is to be performed, and when that work is expected to be delivered.  This will make it easier to get buy in from upper management to purchasing.

• Avoid overwriting the terms of the governing agreement, such as a Master Services Agreement, as any changes to those terms will require legal review and slow down the approval process.

• Review the project specific sections of the SOW with the customer before submission, when possible, so that any confusion or disagreements can be resolved quickly, prior to the SOW being distributed to others for review and approval.  This helps to ensure that SOWs move smoothly.