Stop Scope Creep: Lock Your SOW and Protect Profit

“Can you just add this one button? It shouldn't take long.” This single sentence has destroyed the profit margins of more service providers than almost any other factor. In the world of SMEs and professional services, the project doesn't usually fail because of a catastrophic error; it fails because of a thousand tiny additions that were never part of the original price. At AgreeGold, we see this pattern repeatedly: a service provider signs a contract with a vague Statement of Work (SOW), the client asks for “small favors,” and six months later, the provider is working for free while the project remains unfinishable. This phenomenon, known as scope creep, is not just a management issue; it is a legal failure rooted in how the contract defines—or fails to define—the boundaries of the service.

The Legal Reality of Vague SOWs

When an SOW is written loosely, such as “乙方 will assist 甲方 in building a website,” it creates a vacuum. Many providers believe that being vague gives them flexibility to satisfy the client. The reality is the opposite. A vague SOW shifts the burden of proof onto the provider to explain why a specific request is “extra.”

Under Article 98 of the Civil Code (民法第 98 條), when interpreting a contract, one must seek the true intent of the parties rather than being tied to the literal words used. If the written words are unclear, a court does not simply guess. Instead, the examination focuses on the behavior of the parties during the project. If you have already accepted three “extra” requests without charging or documenting them as changes, those actions become evidence of your “true intent.” Your silence and your compliance effectively redefine the contract. The court may view your past actions as an admission that such tasks were always part of the original scope.

To prevent this, the SOW must be an exhaustive list, not a representative one. If it is not in the list, it does not exist for the purposes of the current price.

Sample Clause: Definition of Services Statement of Work (SOW): The “Services” under this Agreement refer specifically to the items listed in Appendix A (Project Specifications). These include [e.g., development of a booking system with user registration, payment integration, and a backend dashboard]. Any item, feature, or service not explicitly listed in Appendix A, Appendix B, or Appendix C is strictly outside the scope of this Agreement and shall require a separate written agreement and additional fees.

Change Management as a Shield Against “Free Upgrades”

Most service contracts lack a functional change management process. Without a formal mechanism, every client request feels like a negotiation where the provider is at a disadvantage. The client says, “This should be included,” and the provider, wanting to maintain the relationship, says, “Okay, just this once.”

Legally, a contract is formed by the meeting of minds under Article 153 of the Civil Code (民法第 153 條). When a client asks for a change, they are essentially proposing an amendment to the contract. If you do not have a written process to handle these proposals, you lose the ability to track what was original and what was added. The value of a written change procedure is not that it gives you a new right—you already have the right to refuse work you didn't agree to—but that it creates a paper trail.

When a dispute reaches a stage where evidence is examined, the party with the documentation usually wins. If you have a signed Change Order for every modification, the client cannot later claim that the work was part of the original flat fee.

Sample Clause: Change Management Procedure Change Requests: If 甲方 wishes to modify the scope, specifications, or deliverables, 甲方 must submit a written Change Request (including email). Within [Number] business days, 乙方 will provide a written assessment of the impact on the project timeline, costs, and resources. The change will only become effective once both parties sign a written Change Order detailing the revised fees and schedule. 乙方 has the right to decline any work not covered by a signed Change Order.

Acceptance Standards: Ending the “Never-Ending” Project

Service contracts are often categorized as “Contracts for Work” (承攬) under the Civil Code. According to Article 505, Paragraph 1 of the Civil Code (民法第 505 條第 1 項), remuneration is due upon the delivery of the work. This means that if the work is never “delivered” or “accepted,” the client’s legal obligation to pay never matures.

Scope creep often hides in the acceptance phase. A client may refuse to sign off on a project because it doesn't “feel right” or doesn't meet their “expectations.” If your SOW uses subjective terms like “satisfactory” or “high quality,” you have given the client a legal excuse to withhold payment indefinitely.

To close this loophole, acceptance must be tied to objective, measurable criteria. If the software passes the tests defined in the SOW, it is legally “complete,” regardless of whether the client has changed their mind about the aesthetic. Furthermore, you must include a “deemed acceptance” clause. This prevents a client from stalling the project by simply ignoring your delivery.

Sample Clause: Deliverables and Acceptance Acceptance Criteria: 乙方 shall deliver the [e.g., Website Beta] according to the specifications in Appendix A. 甲方 shall have [Number] business days to conduct testing. Acceptance is based on the objective criteria listed in the Functional Requirement Document. If the deliverables meet these criteria, 甲方 must sign the Acceptance Form. If 甲方 fails to provide written notice of specific defects within the testing period, or if 甲方 begins using the deliverables in a live environment, the deliverables shall be deemed accepted in full.

Intellectual Property and the Risk of Silent Transfers

In the rush to define what is being done, many SMEs forget to define who owns what is being made. Under the Copyright Act (著作權法), the default ownership of a commissioned work depends on the agreement. If the contract is silent, Article 12 of the Copyright Act (著作權法第 12 條) specifies that the creator (the service provider) retains the moral and economic rights, but the person who commissioned the work (the client) has the right to use it.

However, problems arise when scope creep involves the creation of new tools, libraries, or templates. If you develop a custom piece of code to solve a client’s problem, and the contract says “all work product belongs to the client,” you may have just sold your proprietary tools for the price of a single project. AgreeGold recommends clearly separating “Client Materials” from “Provider IP.”

Sample Clause: Intellectual Property Rights Ownership of IP: All pre-existing tools, code, templates, and methodologies used by 乙方 remain the exclusive property of 乙方. 乙方 grants 甲方 a non-exclusive, non-transferable license to use these elements solely as part of the final deliverable. Only the specific final output (e.g., the final branding logo) shall be transferred to 甲方 upon full payment of all fees. No IP rights shall transfer until 乙方 has received the total contract price.

Liability and the Ceiling of Risk

Scope creep doesn't just cost time; it increases liability. Every extra feature is a new point of failure. If you agree to add a payment gateway as a “favor,” and that gateway fails, are you liable for the client’s lost revenue?

Without a liability cap, a small project can bankrupt a company. While Article 252 of the Civil Code (民法第 252 條) allows a court to reduce excessive penalties, it does not protect you from general damages for breach of contract. You must explicitly limit your exposure to the value of the contract. This ensures that even if scope creep leads to a dispute, the financial risk is contained.

Sample Clause: Limitation of Liability Liability Cap: To the maximum extent permitted by law, 乙方’s total liability for any claims arising out of this Agreement, whether in contract or tort, shall not exceed the total amount of fees actually paid by 甲方 under this Agreement. 乙方 shall not be liable for any indirect, incidental, or consequential damages, including loss of profits or data.

Order of Operations Before Signing

Before you put your signature on a service agreement, AgreeGold recommends a specific sequence of verification. This is the process we use to ensure our clients are not walking into a trap.

1. The Exhaustion Test: Read your SOW. If a task is not written there, assume you are not doing it. If the client mentioned it in a meeting but it isn't in the document, add it now or prepare to charge extra later.
2. The Objective Trigger: Look at your payment milestones. Are they tied to dates or “approval”? Change every “subject to 甲方’s approval” to “subject to the criteria in Appendix X.”
3. The Change Tax: Ensure there is a clause that explicitly mentions “additional fees” for changes. The mere presence of this clause discourages clients from making frivolous requests.
4. The Silence Break: Check for a deemed acceptance clause. You cannot allow a client’s busy schedule to become your cash flow problem.
5. The IP Boundary: Verify that your background technology is protected. Never sign a “work for hire” clause that doesn't explicitly carve out your pre-existing intellectual property.

Writing a tight SOW is not about being difficult or “unfriendly.” It is about professional clarity. A client who respects your boundaries is a client who will pay on time. A client who refuses to define the scope is a client who will likely never be satisfied, no matter how much extra work you do for free.

FAQ

If the client insists on an extra request not in the contract, can I legally stop work?

You can generally refuse to perform work that is outside the agreed scope. However, you should not stop the entire project unless the extra request is a prerequisite for the original work. Instead, send a formal notice stating that the request is outside the SOW and provide a quote for the additional cost. Continuing to work on the original scope while politely declining the extra work puts you in a stronger position if the client later claims you breached the contract.

What if the client threatens to withhold the final payment unless I add a few more features?

This is a common tactic. This is why the “Deemed Acceptance” and “Objective Criteria” clauses are vital. If you have met the objective criteria, the client is in “default of acceptance” (受領遲延). You should document that the work meets the SOW specifications and issue a formal demand for payment. If the contract is clear, their threat has no legal basis, and you can potentially claim interest on the delayed payment under the Civil Code.

How does the principle of Good Faith apply to scope creep?

Article 148 of the Civil Code (民法第 148 條) requires parties to exercise their rights and perform their obligations in good faith. This means a client cannot use a minor ambiguity in the SOW to demand massive amounts of free labor. However, “good faith” is a high bar to prove in court. It is a safety net, not a primary strategy. A detailed SOW is much more effective than relying on a judge’s interpretation of what is “fair.”

What is the difference between Specifications and Deliverables in an SOW?

Specifications are the “how” and the “standards” (e.g., the website must load in under 2 seconds), while Deliverables are the “what” (e.g., the source code and the hosted URL). You need both. If you only define the deliverable as “a website,” the client can claim it’s not finished because it doesn't meet their unspoken specification of being “fast.” Clear specifications provide the yardstick for acceptance.

Can I charge a deposit before starting work even if the project is small?

Yes. There is no law preventing you from requiring an upfront payment. In fact, for service providers, a deposit (often called a retainer or down payment) is a standard way to mitigate risk. It ensures the client has “skin in the game.” Ensure the contract specifies that this deposit is non-refundable if the project is cancelled by the client without cause, which helps cover your initial resource allocation costs.