SoW preparation guidelines


A Statement of Work (SOW) is a document that describes the offer of service made to a customer and the fee that will be charged for executing the offer. It is a document as important as your contract.

General Tips:
  • SOW is legally binding and hence all clauses/sections need to be reviewed and vetted thoroughly before sign off
  • No section/clauses within a SOW should over-ride provisions/requirements detailed in the governing Master Agreement of the concerned Engagement. Seek review and clearance from legal for any perceived instances of SOW clauses over-riding or increasing stringency/commitments beyond those in the Master Agreement
  • The preferred template for documenting a SOW is the template provided in corporate QC portal. Contents of all sections of SOW template in corporate QC portal shall be factored even if customer provided SOW template is used

Service lines must consult vertical Teams/Counterparts and ensure SOWs being signed for any programs within the engagement, align fully with the governing Master Agreement for all the overall engagement

References:
Ensure that the SOW refers to a Master Agreement and also clearly states the superseding clause between Master Agreement and itself
  • Check the validity of the Master Agreement to ensure it has not expired
  • Any references to Request for Proposal (RFP), RFP responses, customer inputs or any other such document should be supported by annexure to the SOW
  • In case of a 3rd party involvement, a back to back Service Level Agreement (SLA) is to be signed with them and referenced in the SOW
  • All references should have version numbers
Scope:
  • While defining the scope of work, clearly state the
  • functional as well as the non-functional scope
  • When requirements are at a high level, ensure that there is mention of obtaining sign off on the Requirement Specification (RS), High Level Design (HLD), Test Plan and Acceptance Plan
  • Clearly define the acceptance criteria and ensure a deemed acceptance clause with mutually agreed timelines
  • Ensure traceability of the items mentioned in the scope section to the execution plan and deliverables section in the SOW
  • Do not make generic and open ended
  • statements like'all browser compatibility1 unlimited interfaces','fast performance7significant improvement',' internationalization/localization'
  • Clearly document the measurement criteria for all non functional requirements (upload time, number of records uploaded, response time, real time v/s batch, throughput)
  • Avoid committing to participation in quality improvement initiatives unless we are clear on what the initiatives are and improvement is feasible

Project Schedule
  • Cross check if the project milestone is in line with the customer's internal milestone if any, specified in the RFP
  • If there is any performance linked payment based on schedule, clearly document assumptions and critical dependencies for meeting the project schedule
  • Avoid using words like timely and best efforts. Instead use, mutually agreed timelines/efforts

Execution
  • Always define a RACI matrix (Responsible, Accountable, Consult, Inform) including the third party and the customer to clarify the responsibility/onus of various activities within the project
  • Review all report formats and templates before you agree on submission
  • Always mention the model numbers/version numbers of any tools, software, hardware, documents used or referred to in the project
  • Ensure that the team will be informed of any changes in the specification

Opensource and Intellectual
  • If there Is usage of open source, include the standard open source indemnification clause in the SOW
  • If SOW requires Authorized Signatory's to sign the certificate of originality, need to contact IP Counsel in the organization for Approval

Environment
  • Ensure cost required to return customer supplied material to be borne by the customer
  • Ensure that the target environment and the development environment are in sync
  • Mention the license and version numbers for all hardware & software used in the project environment

Milestones and payments
  • While linking payments to acceptance of deliverables - In case this is required, agree on the acceptance criteria and then fix the time frame for acceptance
  • If there are any performance linked payments, do a sensitivity analysis to understand the feasibility of achieving the performance factor and negotiate
Warranty Support
  • Warranty period should be mutually agreed and should not be beyond 6 months
  • Clearly state the scope of activities, location covered and any infrastructure requirements for warranty
  • Include the warranty cost in the overall pricing