by Zin Kortebi and Victor W. von Buchstab
The Statement of Work (SOW) is the link between an organization wishing to engage an external organization to accomplish some work; and a vendor engaged to provide services toward accomplishing that work. It is a binding contract that holds each party–the vendor and the organization that has retained the vendor–accountable for commitments necessary for project success. It is the basis upon which project decisions involving the vendor are made. Given its significance, the SOW has the power to elevate your project to lofy heights or send it plummeting to the ground. Here are five things to consider before signing on the dotted line:
1. Strive for mutual success
The whole point of vendor engagement is to realize opportunity: There is something to be gained for both the vendor and the customer. As such, SOW preparation should be a collaborative endeavor focused on benefits for both parties. Leave time for this collaboration as it may take several iterations to develop a SOW that meets the needs of customer and vendor; rushing things now will add risk that, if realized, could outweigh any up-front efforts to clarify understanding. Surprises are costly to the project and the customer/vendor relationship. The objective, here, is to work together to avoid them.
2. Clarify and elaborate deliverables into sufficient detail
What constitutes delivery? In fixed-price engagements, this is a key question to be addressed in the SOW as it determines when funds will be released to the vendor. Specify what the deliverables are, when they will be delivered, and the acceptance procedure–including how the team will verify the deliverables have, in fact, been delivered. The degree to which deliverables must be elaborated depends on the project. For example, if a vendor is being engaged to automate a customer’s business processes for a fixed price, is it sufficient to define the number of automated processes that will be delivered? Probably not–what if one (or several) of the processes have hundreds of steps? In this case, there will be disagreement between the vendor and the customer over payment because the effort required is not aligned to the specified deliverable; because the customer and vendor have different perceptions of the the deliverable; because the deliverable isn’t elaborated to sufficient detail. (This a real example we have seen; it wasn’t pretty; and less eloquent words were used to describe the “disagreement between the vendor and customer”.)
3. Clarify accountabilities
A well-prepared SOW will specify commitments and expectations for both the vendor and the customer. When is the vendor required to participate in the project? Will work be done on-site or remotely? What specific resources/skills will the vendor provide? What customer resources/skills does the vendor require to be successful? When are these resources required? What is the impact/remedy if customer resources are not available when required? These are just a few questions that should be specified in the SOW.
4. Confirm implementation approach
The SOW should include discussion of how the vendor will achieve its objectives. This may have already been described in a proposal (if there was one) prior to the SOW; and should be specified in greater detail. Will an agile approach be followed? Is the customer team prepared for this; or will agile training be required? How will vendor performance be tracked and reported? Will the vendor supply a project manager? If so, where is the line between the vendor PM and the customer PM?
5. Know the difference between a proposal and a SOW
Proposals are not SOWs. When vendors submit proposals in response to a Request for Proposal (RFP), they’re in Sales mode. The wording is high-level; deliverables are not specified; and any terms and conditions are vague–often because not enough information is known, and they don’t want to risk scaring off a potential customer. Proposals do not provide sufficient detail for making project decisions such as, for example, what constitutes delivery of a specific work item. Rather, the SOW elaborates the proposal by spelling out, in detail, what both the customer and the vendor have signed up for. “Should” is a proposal; “Must” is a requirement. Watch for words such as “approximately” and “basic” which are red flags that the SOW is not detailed enough–the vendor’s definition of “basic” may be different from that of the customer.
Whether you are a vendor or a customer, we hope these tips will help you develop SOWs that are mutually beneficial. Got a question regarding a SOW? Contact us–we’ve been doing this for a while; and happy to help. To find out more about our vendor engagement services, please visit us at Professional Services Plus.
