A client asks for “one small addition”. The delivery team begins work because the request sounds reasonable. Later, the invoice includes an extra charge, but the client believes the addition was already covered. Both sides remember the conversation differently.
For Indian service businesses, a clear scope of work and a usable change process can make these conversations more precise. The objective is to connect the commercial promise, the work being delivered and the approval needed when that work changes.
The short answer: describe the deliverables, assumptions, responsibilities and acceptance process before work begins. When a change is requested, identify its effect on scope, fees, timing and dependencies, then follow the agreed authorisation process before treating the revised work as approved.
This IFF Law Attorney article is general educational information. It provides questions for contract preparation and review, not a ready-to-sign clause or advice on a particular dispute. The legal effect of a document or exchange depends on the contract, applicable law and circumstances.
What is a scope of work?
A scope of work, often called an SOW, describes the work that the parties intend to perform under a project or service arrangement. Its title matters less than whether it fits clearly with the rest of the contract.
For a design project, the scope might identify the outputs and review stages. For a technology service, it might describe the work environment, responsibilities and deliverables. For a consultancy engagement, it might define the report, meetings and information the client must provide.
Avoid using a broad phrase such as “complete support” without explaining what it covers. Different people can attach different expectations to the same phrase, especially when the commercial team and delivery team were not part of the same conversation.
A useful review begins with a practical test: could someone who joined the project tomorrow understand what must be delivered and which questions remain open?
Describe outputs in a way the team can check
Start with the deliverable, its intended format and the boundaries of the work. Identify any stages that need separate review or approval.
For example, “prepare a presentation” leaves several questions unanswered. How many distinct deliverables are expected? Who provides the source material? Which editable files are included? How will feedback be collected? What happens if the brief changes after a stage has been approved?
The agreement should address the questions relevant to the actual engagement. It does not need to contain every imaginable detail, but important commercial assumptions should not exist only in a salesperson’s memory.
Check the description with the people who will perform the work. They may identify dependencies or practical limits that are not obvious from a proposal. Legal review is more useful when the commercial team has already explained what the project is intended to do.
Illustrative scope document. The contents of an actual agreement should be tailored to the transaction and reviewed in context.
State assumptions and client responsibilities
A delivery schedule may depend on access, information, feedback or decisions supplied by the client. If these dependencies are not described, a date can appear unconditional even when the team cannot proceed alone.
List the important inputs and identify who is expected to supply them. Discuss what happens if information is incomplete, inaccurate or delayed. The agreed response may involve a revised schedule, further discussion or another mechanism appropriate to the contract.
Separate an assumption from a verified fact. If a quote assumes that existing material can be reused, confirm who will establish whether it is available and suitable. If access to a system is required, describe the authorised route rather than casually sharing credentials in the project brief.
Review these responsibilities with the client’s operational contact as well as the person negotiating price. A commercially approved arrangement can still be difficult to deliver if the person responsible for an input does not know that it is expected.
Define how work will be reviewed
“Subject to approval” is incomplete unless the parties understand what is being reviewed and how the review will take place.
Discuss the review criteria, the person or role responsible for responding and the way comments should be communicated. Consider whether feedback should be consolidated so that the delivery team receives a coherent instruction rather than contradictory messages from several stakeholders.
Distinguish correction of an agreed requirement from a request for a new requirement. The contract should help the parties discuss that difference without assuming that every comment is automatically chargeable or that every new request must be included.
Any provision concerning response periods, acceptance or the consequences of silence should receive careful legal review. Do not copy a generic “deemed accepted” sentence and assume it will suit every customer, industry or transaction.
The practical aim is a review process that both parties can actually follow and document.
Explain what triggers a change discussion
A change may involve a new output, a different brief, additional versions, revised timing or an altered dependency. The trigger should be described in terms relevant to the engagement.
Prepare the team to recognise a request without immediately accepting or rejecting it. A useful initial response is to record what has been asked and confirm that its effect will be reviewed under the agreed process.
This keeps a helpful conversation from becoming an unclear commitment. The delivery team can remain responsive while the authorised people assess the commercial and contractual implications.
Avoid relying only on the phrase “out of scope”. Explain the existing requirement, the requested difference and the reason it needs review. A precise comparison is easier for the client to assess than a label that sounds like a refusal.
Conceptual workflow: record the request, review its impact and obtain the approval required by the agreement. This diagram does not establish legal validity on its own.
What should a change record contain?
A useful change record connects the new instruction to the existing contract. Depending on the arrangement, it may be called a change order, variation, amendment or another agreed term.
Consider recording:
- The contract or project reference and the current scope revision.
- The requested change and the reason for it.
- The deliverables or activities affected.
- Any proposed change to fees, payment milestones or expenses.
- The effect on dates, dependencies and client responsibilities.
- Which existing terms continue to apply and any proposed exceptions.
- The people authorised to approve, the required approval method and the effective date.
These are drafting prompts, not a universal legal form. The document must work with the agreement it changes and any formalities that apply.
India’s Contract Act includes Section 62 dealing with novation, rescission and alteration of contract. That statutory context is one reason amendments should be reviewed as part of the overall contractual arrangement, rather than treated as isolated project notes. India Code: Indian Contract Act, 1872
Check authority before relying on an approval
The person who discusses a change may not be the person authorised to approve its commercial effect. The project team should know the agreed approval route.
Identify the appropriate roles and communication channels in the contract or project governance documents, with legal advice where needed. If a contact changes, update the operational records through the agreed process.
Do not assume that copying a senior person on an email resolves an authority question. Equally, do not assume that a message has no significance merely because it was informal. The legal effect requires assessment in context.
Where there is uncertainty, clarify it before the team builds further work around the instruction. A short, specific question at the right moment can be easier to resolve than a disagreement after substantial work has been completed.
Keep price, timing and scope connected
A change discussion should not consider the additional fee in isolation. New work may affect sequence, resource availability, review stages or the date of another deliverable.
Ask the delivery team to explain those effects in practical terms. For example, an extra version may require another review cycle, or a revised input may make an earlier stage unsuitable for reuse. The client needs enough information to make an informed commercial decision.
Record what remains unchanged as well as what is being revised when that is necessary to understand the amendment. Avoid leaving two schedules or fee descriptions that appear to apply at the same time without explaining their relationship.
The appropriate payment and timeline provisions depend on the transaction. Have them checked together so that an amendment does not unintentionally conflict with the original agreement.
A clear change process turns “Can you also do this?” into a decision about work, time, price and authority.
Editorial takeaway from this IFF Law Attorney checklist.
An illustrative service-project example
Consider a fictional business engaged to prepare a defined set of training materials. After the first review, the client asks for a second audience version with different examples and an additional workshop.
The service provider records the request and compares it with the agreed outputs. The team identifies the additional preparation, the review needed from the client and the effect on the original delivery sequence. The authorised representatives discuss a written change record that addresses the revised scope, commercial terms and timing.
The example does not assume that the provider is automatically entitled to additional payment or that a particular form of message creates a binding amendment. Those questions depend on the actual arrangement. The useful lesson is procedural: make the difference visible and resolve the relevant questions before treating the revised plan as settled.
This is a hypothetical scenario, not an IFF client matter, a court decision or a promised legal outcome.
Illustrative business review. The commercial team, delivery team and legal adviser should work from the same current documents.
Maintain one current project record
Contracts can become difficult to administer when approved changes are scattered across several folders and conversations. Keep a controlled record that identifies the operative agreement and the changes made to it.
Use clear file names and revision information. Retain relevant correspondence and approvals according to the organisation’s retention and access policies. Restrict access where the documents contain confidential information.
Give the delivery team a usable summary of the obligations it needs to perform, while preserving access to the actual contractual documents through the appropriate channel. A project tracker should support the agreement rather than quietly rewriting it.
At project closure, check whether any agreed changes remain incomplete or unresolved. Record the position accurately instead of treating the final invoice as a substitute for the required completion or acceptance process.
Questions Indian service businesses often ask
Is a scope of work the same as a quotation?
They can overlap, but their role depends on the documents and how the agreement is formed. A quotation may describe price and assumptions without addressing all the terms needed for delivery. Review the documents together.
Can a WhatsApp message approve extra work?
Do not assume a universal answer. The message, the parties’ authority, the contract’s requirements and the surrounding circumstances may all matter. Obtain advice on the actual exchange and use a clear agreed process going forward.
Should every small request lead to a new fee?
That is a commercial and contractual question. Some requests may fall within the agreed work or review process. Others may require a change discussion. Define the distinction clearly rather than applying a blanket rule.
Can I use a change-order template from another project?
A template may be a useful starting point, but the scope, approval route, contract terms and applicable requirements may differ. Have it adapted and reviewed for the transaction before relying on it.
Make the agreement usable during delivery
A professional service contract should help the team understand what to do when a real project changes. Clear outputs, responsibilities, review stages and authorisation routes make that discussion more structured.
Before adopting or revising a scope-of-work process, have the proposal, main agreement and sample change requests reviewed in the context of the engagement. The most useful preparation is a clear explanation of how your business actually sells, delivers and approves its work.