Most IT project disputes in India come down to one document that wasn't written carefully enough — or wasn't written at all. The Statement of Work is the contractual document that defines exactly what will be delivered, by when, for how much, and under what conditions payment is due. Without a solid SOW, "we'll add that small feature" becomes a three-month delay, and "the project is complete" means entirely different things to the client and the developer. This guide is written for both parties: IT service providers who need to write SOWs, and business owners who need to review them before signing.
What a Statement of Work Is (and What It Isn't)
A Statement of Work is a project-specific document that defines scope, deliverables, timeline, and payment. It typically sits inside or alongside a broader Master Service Agreement that covers the general terms of the relationship between a client and a service provider.
What it is not: a proposal (which is the document you send before the client decides to hire you), a standalone contract (which provides the legal framework and jurisdiction), or a project plan (which is internal to the implementation team and describes tasks, not commitments).
The SOW answers exactly five questions: What will be built? How will it be tested and judged acceptable? What is explicitly excluded? When will it be delivered? How much will it cost and when are payments due? Every dispute that arises on an IT project can be traced back to ambiguity in the answer to at least one of these questions.
The 8 Sections Every IT SOW Must Include
A complete Statement of Work for an IT project contains eight sections. Omitting any of them creates a gap that will be filled by each party's assumptions — and those assumptions are rarely identical.
1. Project Overview. Two to three sentences describing what is being built and why. This section anchors the document — if a dispute arises, the project overview is the first reference for understanding original intent.
2. Scope of Work. A detailed list of what will be delivered. This is the most-litigated section and the one that requires the most precision.
3. Out of Scope. An explicit list of what is NOT included. This section is frequently missing from SOWs written by inexperienced developers and is the source of the majority of scope creep disputes.
4. Deliverables. Specific, measurable outputs — not activities. "Develop the payment module" is an activity. "A tested Razorpay payment gateway integration that processes INR transactions and returns order confirmation on success" is a deliverable.
5. Timeline and Milestones. Specific dates with percentage-of-completion markers at each milestone. "By end of project" is not a timeline.
6. Acceptance Criteria. The objective standard by which each deliverable will be judged complete. This section makes "done" measurable rather than subjective.
7. Payment Terms. The schedule of payments, tied directly to milestone completion rather than calendar dates.
8. Change Management Process. The formal procedure for requesting, assessing, approving, and pricing changes to scope after the SOW is signed.
Writing the Scope of Work Section
The scope section is where most project disagreements originate and where the most care is required. The test for a well-written scope: can two people read this independently and agree on whether a specific feature is included or not? If the answer is no, the scope isn't specific enough.
Here is the difference between a scope statement that will cause disputes and one that will not.
Weak scope: "Develop a mobile app for the client's business."
Strong scope: "Develop an Android (API level 28 and above) and iOS (iOS 15 and above) mobile application including: user registration via email and Google OAuth, a product catalogue supporting up to 500 SKUs at a single category level, a shopping cart and checkout flow with Razorpay payment gateway integration, an order history screen showing the last 90 days of orders, and push notifications for order status changes (placed, shipped, delivered). The application will be submitted to the Google Play Store and Apple App Store under the client's developer accounts."
The strong scope is verifiable at every point. When the client later asks for sub-categories, a wish list feature, or social login via Facebook, the developer can point to the exact scope language and the change request process applies. Without that language, the client's position that these were "obviously included" is difficult to contest.
The Out-of-Scope Section — Often Missing, Always Important
Explicitly listing what is not included is as important as listing what is. Clients frequently assume that related work is part of the project unless they're told otherwise. The out-of-scope section creates that clarity without requiring a confrontational conversation at the moment a request arrives.
Examples of items that belong in the out-of-scope section for a typical web development project:
- Content writing, photography, and graphic design beyond the UI specification
- SEO beyond technical implementation (meta tags, sitemap, robots.txt)
- Third-party service integrations not listed in the scope section
- Multilingual support beyond the languages specified
- Bug fixes reported more than 30 days after the go-live date
- Staff training beyond two hours of video walkthrough recordings
- Hosting setup, domain management, and SSL configuration
For Indian IT projects, these items are particularly prone to being assumed by clients but need to be explicit: GST return filing integration, WhatsApp Business API notification setup, custom GSTIN invoice PDF generation, and UPI deep link integration. These are non-trivial features that represent separate development scope, and clients often assume they come with any business application.
Acceptance Criteria — Making "Done" Objective
Acceptance criteria define when a deliverable is complete for payment purposes, and they are the clause that makes the payment terms enforceable. Without clear acceptance criteria, a client can delay sign-off indefinitely by finding minor issues — and a developer has no recourse.
Criteria must be measurable, not subjective. "The application works correctly" is a subjective standard. "All 47 test cases listed in Appendix A pass without errors on the specified devices" is a measurable standard.
Include a deemed acceptance clause — this is standard practice and is enforceable under the Indian Contract Act: "If the client does not provide written acceptance or written feedback identifying specific failures against the agreed acceptance criteria within 7 business days of delivery notification, the deliverable is deemed accepted and the corresponding milestone payment becomes due." This clause protects developers from indefinite review periods and gives clients a clear deadline to raise legitimate issues.
The review period should be proportionate to the deliverable size. Seven business days is appropriate for a feature module; 14 days may be reasonable for a full application handover. The specific number matters less than having a number.
Payment Terms Tied to Milestones
Never accept payment-on-completion terms for any project lasting more than four weeks. The financial and operational risk is entirely on the service provider, and it creates an incentive for clients to delay sign-off.
A workable milestone payment structure for a four-month project:
- 30% on signing and project kickoff
- 20% on completion of design and architecture review
- 25% on completion of development and internal QA
- 15% on client UAT sign-off
- 10% on go-live and formal handover
In India, TDS (Tax Deducted at Source) applies to professional and technical services. If the client's total payments to a single service provider exceed ₹30,000 in a financial year, the client is required to deduct TDS at 10% under Section 194J of the Income Tax Act before making payment. This is frequently misunderstood — both parties sometimes assume the quoted project fee is what the developer will receive, when actually the client must deduct TDS from each payment. The SOW should state this explicitly: "All amounts are exclusive of applicable TDS. The client is responsible for deducting TDS as required under Section 194J and providing a TDS certificate within 15 days of each payment."
Change Management — The Scope Creep Kill Switch
Scope creep — the gradual expansion of project scope through accumulated small requests — is the most common reason IT projects exceed budget and timeline. Each individual request seems reasonable. The cumulative effect is a project that delivers at 130% of the original scope for 100% of the original budget.
A formal change management process is the only reliable protection. The process should be documented in the SOW as follows:
- The client submits a Change Request in writing using the agreed format (email is sufficient if it identifies the requested change clearly)
- The service provider responds within 3 business days with an impact assessment covering additional cost, timeline extension, and scope changes
- The client approves or rejects the Change Request in writing
- Development on the requested change begins only after written approval
- Oral change requests made during calls or site visits are not valid without written follow-up confirmation
The change log — a running record of all submitted, approved, and rejected Change Requests — becomes an appendix to the SOW. At project close, this log documents exactly why the timeline or budget differed from the original estimate, which prevents end-of-project disputes about what changed and who approved it.
Indian-Specific Clauses to Include
Several clauses are particularly important for Indian IT project SOWs and are frequently omitted.
Jurisdiction and governing law. Specify the courts and state whose law governs the agreement. For Kerala IT projects, "The courts of Thiruvananthapuram / Ernakulam, Kerala shall have jurisdiction over any dispute arising from this agreement, and the agreement shall be governed by the laws of India." This prevents a situation where one party attempts to file in a distant jurisdiction to gain tactical advantage.
Force majeure with India-specific events. Standard force majeure clauses reference natural disasters and wars. For Kerala projects, add: internet and power outages lasting more than 24 consecutive hours, official bandh and hartal days recognised by the state government, and flooding during the monsoon season. This protects both parties when external events — not performance failures — cause delays.
DPDPA compliance clause. If the project involves processing personal data of Indian citizens, include: "The service provider shall process personal data only as required for delivery of the services described in this SOW. The service provider shall not retain personal data beyond 90 days following project completion without written instruction from the client. Both parties acknowledge their obligations under the Digital Personal Data Protection Act, 2023."
GST specification. State explicitly whether quoted amounts include or exclude GST. Standard practice: "All amounts in this SOW are exclusive of applicable Goods and Services Tax. GST will be charged additionally at the applicable rate." Both parties should ensure they have valid GSTIN registrations, and the developer's invoices must include both GSTINs to enable the client to claim input tax credit.
Frequently Asked Questions
Can a WhatsApp conversation serve as a valid SOW in India?
Under the Indian Evidence Act and the Information Technology Act 2000, electronic communications including WhatsApp messages can be admissible as evidence in Indian courts. However, WhatsApp conversations are not a substitute for a formal Statement of Work — they lack the structure and completeness that a court needs to determine what was actually agreed. They're also easy to screenshot selectively, which makes them a weak foundation for either party in a dispute. For small, short-duration projects, a well-written email that covers scope, payment, and timeline is enforceable and practical. For any project above ₹50,000 or running longer than four weeks, a formal SOW document signed by both parties is the appropriate standard. DocuSign, SignDesk, and Zoho Sign all support legally valid e-signatures under Indian law and make signing a two-minute process.
What should I do if a client changes requirements mid-project without formally approving a change request?
The key is to document the request immediately in writing, without waiting for the client to escalate the conversation. Send a follow-up email after any call where new requirements were discussed: "Following our conversation today, I understand you'd like to add [specific feature]. This addition is outside the scope defined in our SOW dated [date]. Please let me know if you'd like me to prepare a Change Request with the cost and timeline impact." This response creates a written record, signals that the change is not free, and does so without confrontation. If the client insists the change was always part of the project scope, go to the SOW and show them the specific scope language. In most cases, clear scope language resolves the disagreement at this stage. If the dispute reaches a formal level, Indian courts applying contract law will read the SOW language as written — the document governs, not the parties' post-signing recollections.
What's a reasonable SOW for a Kerala small business hiring a freelance developer for ₹80,000?
At ₹80,000, a formal SOW is entirely appropriate and takes less time to write than most developers expect. A 2–3 page document structured as: a one-paragraph project description, a scope list of 10–20 specific features or pages, an out-of-scope list covering 5–10 commonly assumed items that won't be included, a timeline with start date, two or three intermediate milestones, and a completion date, a payment schedule (40% on signing, 30% on completion of development, 30% on client acceptance), and a 7-day acceptance review window with deemed acceptance language. Both parties sign it — digitally via Zoho Sign or by exchanging scanned signatures. The developer needs 2–3 hours to draft this; the client needs one hour to review and negotiate minor points. The upfront investment in this document will prevent disputes that would otherwise consume far more than three hours — plus the stress, relationship damage, and potential legal cost of a project that ends in disagreement.