Statements of work are the industry standard contracting vehicle to describe the services that will be provided by a vendor to a customer. This document represents the scope of work that will be done, the cost and the billing model that will be used (fixed price or hourly are the two most common). A lot of care an attention needs to be put into your statement of work if you want to avoid potentially nasty issues down the road in your project. Remember that a good contract to a customer is like a good fence to a neighbor.
No Acceptance Criteria for Deliverables
In your statement of work you will have a set of deliverables – tangible items that you are ‘delivering’ to the customer, whether it’s actual software or perhaps other consulting services (training, discovery, etc.). What will get you into trouble almost every time is not having definitive, unambiguous criteria that defines acceptance for each deliverable. I.e. defining the finish line that both the vendor and the customer say will constitute full delivery of that item. While you may have some disputes during your project on whether that criteria has been met, it’s important to have that common understanding of what will make that deliverable ‘accepted’ in the eyes of both vendor and customer.
Ambiguous Language to Re-Align Payments
In a time-and-materials contract, this is less of an issue but for fixed price contracts, normally payments will be lined up to achievement of specific milestones or batch of deliverables with dollar amounts tied to each of these achievements. Sometimes what may happen during contracting is the customer (or even vendor) may add language into the contract to allow for the re-alignment of payment amounts among deliverables/milestones but without any supporting detail behind it. This can lead to a number of issues (most notably cash-flow for the vendor) if clauses like this are included in your contract. While there is always the ability to re-align payments should project conditions call for it, it’s better to leave that language outside of the statement of work and let it be addressed through the formal change control process.
Not Specifying Fixed Price/Fixed Schedule Parameters
Often times in fixed price contracts there isn’t specification around what would trigger a monetary change order to pay for additional time that resources need to spend on the project to support a customer. Example – in a testing phase of the project, the project managers will develop a schedule for testing to take place. This can be a challenge to get right since there are a number of unknowns such as the number of bugs that will be found or how long it will take to fix them. Or for such things as testers simply just taking longer than planned to get their tests done, possibly due to interference from their day jobs. Either way, it is important to specify in your contracts that if it’s fixed price and fixed schedule, that language be included to say that if there are delays, that it is on the offending party to either make up the lost time or be prepared to be financially responsible for the delays.
Comments