When assuming the lead of a project one of the first jobs a project manager needs to do is get very familiar with the contract governing your project. Whether it is a net new project or stepping into an ongoing project, doing a thorough contract review is vital to getting off on the right foot. This post will call out some all-too-common flaws in project contracts (or otherwise known as statements of work).
Lack of Clearly-Defined Deliverables
The heart of a good contract is explicitly calling out the project deliverables (i.e. what is your organization going to give to your customer in exchange for your fees). A project will have many deliverables (or at least it should) and depending on the pricing model of your project, you may have payments associated to the successful delivery (and possibly acceptance) of these deliverables.
When defining a deliverable in a contract it’s important to call out in as much detail as possible what the deliverable will consist of, how it will be furnished to the customer and at what stage of the project it will be delivered. For example, if you have a design document as one of your deliverables, the contract should call out as many specifics about it that are known at the time such as the format it will be delivered in (MS Word, PDF, etc), key sections (solution objective, functional requirements, screen mock-ups, business processes, etc) or even what the predecessors or successors are to the delivery of the deliverable.
Loose Acceptance Criteria
Nothing will cause a disagreement quicker in a project than loosely-worded language around acceptance criteria of your deliverables. Acceptance criteria that is agreed upon between yourself and your customer (in writing) will save so much pain down the road of the project that it is worth the extra effort needed to ensure customer support of the criteria. When reviewing your contract if you detect language in your acceptance criteria that you feel your customer could interpret in a way that you or your organization wouldn’t, it’s important to get in front of that early and work with your customer to revise the language to ensure it meets the spirit of the original intention of the deliverable.
Minimal Customer Accountability
This is often overlooked when reviewing contracts but it’s very important to ensure that the customer has some skin in the game when it comes to the successful delivery of the project. Typically, this is done through the commitment of resources to achieve some aspects of the project plan, such as solution adoption and/or championing, system testing and feedback, participation in business requirements definition or even project management. If the customer is only responsible for paying the invoices this should be considered a warning sign (not always, but often) that you may not have the support from inside the customer organization that you need to make this a truly successful project.
Not all contracts are bad, but depending on the nature of the project or even the customer relationship, a strong, but fairly-worded contract protects both parties and ensures that expectations are set early on and that deviations from the agreed scope and objectives of the project will be kept to a minimum.