How to write a statement of work for a software project

Last updated: 2026-10-18

A statement of work (SOW) for software development defines what you are paying for, how you will decide whether the work meets the agreed requirements, and what happens when the scope changes. The last two points deserve particular attention. In a survey of 228 companies, 48% cited incomplete or hidden requirements as a critical problem, and 33% cited changing requirements.

Key facts

In this article

• What is a statement of work, and how is it different from a spec?
• What sections does a statement of work for software development need?
• How do fixed-price and time-and-materials contracts move risk?
• How do you write acceptance criteria a vendor can test?
• How should a change request work?
• When should you pay, and when should you own the code?
• Where RocketDevs fits
• Conclusion: the bottom line
• Frequently asked questions

This buyer’s guide covers the commercial and practical side of a software statement of work, drawing on published model contracts, government procurement rules and research. It is not legal advice. The laws governing your contract depend on your jurisdiction and the vendor’s, so have a lawyer qualified in the relevant jurisdiction review any agreement before you sign it.

What is a statement of work, and how is it different from a spec?

A statement of work (SOW) defines what a vendor must deliver and how you will judge whether the work is complete. A product specification describes what the software should do. The US government's definition of a performance work statement captures the first purpose: it describes required results in clear, specific and objective terms with measurable outcomes, according to Federal Acquisition Regulation (FAR) 2.101.

The distinction matters because founders often hand a development agency a product spec and assume it defines the entire scope of work. A spec, such as the one described in how to write a product spec developers can build from, answers "what should this software do?" A statement of work answers four additional questions: what exactly will the vendor deliver, how will both parties know it is finished, what happens when requirements change, and when do payment and ownership transfer? The spec will often be attached to the SOW as a description of the deliverables, but it does not replace the agreement about how the work will be delivered and accepted.

FAR 37.602 directs agencies, to the maximum extent practicable, to describe work in terms of required results rather than prescribing how the vendor must do it or how many hours they must provide. It also calls for measurable performance standards. This is useful advice for private buyers too. "Build a login page using React" specifies a method. "A registered user can sign in with an email address and password, and an incorrect password displays an error without revealing whether the email address exists" defines a result you can test.

The US Department of Defense's SOW handbook, MIL-HDBK-245D, makes the same point, recommending clear, understandable descriptions of the work and specific, measurable performance requirements. Although the handbook dates to 1996, its underlying principle remains useful when drafting software contracts.

Where it sits in the contract

Software engagements commonly use two layers of documentation. A master services agreement (MSA) or professional services agreement establishes the general legal terms, such as liability, confidentiality, termination and governing law. Each project or phase of work then has its own statement of work, which sets out the specific deliverables, schedule, acceptance criteria and payment arrangements. As Wikipedia's overview of statements of work explains, an MSA can govern the terms of multiple SOWs.

The UK government's Digital Outcomes framework follows this structure. Its statement of work template provides for the parties to execute an SOW for each set of required buyer deliverables.

This division helps you separate recurring legal terms from project-specific commitments. Your lawyer can establish or review the general contractual framework, while each SOW records what the vendor must deliver for that particular engagement. The SOW is also where many practical disagreements arise: whether a feature was included, whether the work meets the agreed standard, and whether a requested change costs extra.

Why the writing matters more than it looks

Research into software project problems repeatedly points to requirements, communication and changing expectations. These are precisely the areas a well-written statement of work should address.

In the NaPiRE survey of requirements engineering across 228 companies in 10 countries, the three most frequently reported critical problems were incomplete or hidden requirements (48%), communication problems between teams and customers (41%), and changing requirements (33%). The researchers also identified these as the three most frequently cited problems associated with project failure.

An earlier industrial survey covering 164 projects in Australia and the US found that nearly half began with incomplete requirements. It also found that the best predictor of success was good requirements that were managed effectively. A study of 12 software companies concluded that most requirements problems are organisational rather than technical.

These organisational problems are where a clear, mutually agreed SOW can help. It can establish who makes decisions, who approves deliverables, what counts as completion, and how changes must be agreed and priced. It cannot guarantee that a project will succeed, but it can reduce the room for conflicting expectations.

You will often see much larger failure-rate figures attributed to the Standish Group's CHAOS reports. Treat those numbers cautiously. Researchers examining 5,457 forecasts from 1,211 real projects argued that the Standish definitions of project success and failure were misleading and produced meaningless figures. A separate review questioned the widely cited 189% average cost overrun in the 1994 report, arguing that the figure should be treated with scepticism until the underlying measurement method was disclosed.

The practical conclusion is less dramatic but more useful: requirements problems are common, and many stem from unclear expectations, communication failures and changing scope. A statement of work gives both parties a shared record of what they agreed to deliver, how completion will be judged and what happens when the agreement needs to change.

What sections does a statement of work for software development need?

At minimum, the US government says a statement of objectives must cover six areas: purpose, scope or mission, period and place of performance, background, performance objectives (the required results), and operating constraints, according to FAR 37.602. A private software statement of work needs those foundations, plus four areas that help prevent disputes: acceptance, change control, payment terms and intellectual property.

The table below is a practical starting point for founders writing their first SOW. It explains what to include in each section and what can go wrong when the wording leaves too much room for interpretation.

A few of these sections deserve closer attention because their wording can have a direct effect on cost, delivery and ownership.

Deliverables. The US Department of Defense's SOW handbook warns against vague language. It identifies words and phrases such as "any", "assist", "as required", "as applicable/as necessary" and "as directed" as common problems when defining tasks, and tells drafters not to use them.

Search your draft for these expressions before signing. Each one can conceal a disagreement about what the vendor is actually required to do. Replace "assist with user onboarding", for example, with a defined deliverable such as a registration flow, an email verification process and a password-reset function, each with its own acceptance criteria.

Price. The UK government's Digital Outcomes 6 statement of work template requires the buyer to select a charging method for each SOW. Options include capped time and materials, incremental fixed price, time and materials, fixed price, or a combination. It also asks for the estimated maximum value of each SOW, regardless of the selected charging method.

Adopt the same discipline for your project. State how the vendor will charge, what triggers each payment, and the maximum you are authorised to spend. A spending cap does not guarantee that the vendor will finish every feature within that amount, so also specify what happens if the budget is exhausted before the agreed deliverables are complete.

Specifications. You do not need to dictate every technical decision to define a satisfactory result. Article 42 of EU Directive 2014/24/EU allows public procurement requirements to be expressed through performance or functional requirements, provided they are precise enough for bidders to understand the subject of the contract.

The UK's Digital, Data and Technology Playbook similarly warns that "over-specification is the approach least likely to lead to success". The principle for a private software buyer is straightforward: be precise about the outcome, but avoid unnecessarily restricting how the vendor achieves it. Specify the required behaviour, security standards, integrations and performance levels where they matter, while leaving reasonable implementation choices to the development team.

If you are commissioning the first version of a product, define the smallest release that can test your idea before putting the scope into the contract. Our guide to MVP development for startups explains how to prioritise essential features and leave non-essential work for later.

How do fixed-price and time-and-materials contracts move risk?

Fixed-price contracts put most of the cost-overrun risk on the vendor, while time-and-materials (T&M) contracts put more of it on you. Under a firm-fixed-price contract, the vendor takes "maximum risk and full responsibility for all costs and resulting profit or loss", according to FAR 16.202-1. T&M contracts may be used only when the extent or duration of the work cannot be estimated accurately at the time the contract is placed, per FAR 16.601. Neither model is automatically safer. Each allocates risk differently, and certain clauses can shift that risk back to the buyer.

Who carries the estimate risk

Every software contract contains an estimate, and software estimates have a particular weakness: while many projects finish relatively close to budget, a smaller number experience extreme overruns. Research covering 5,392 IT projects found that cost overruns followed a power-law distribution, with a small number of projects accounting for exceptionally large overruns. Our guide to estimating how long a software feature will take explores the estimation problem in more detail. The contract question is simpler: when the estimate proves wrong, who pays?

With fixed price, the vendor generally bears the cost of completing the agreed scope for the agreed price. That is why vendors account for uncertainty when quoting and protect themselves against scope changes. The US Digital Service's TechFAR Handbook warns that poorly defined requirements can make fixed-price contracts more expensive because vendors build contingencies into their bids. Tight scope wording and formal change control are not necessarily signs of bad faith; they are ways of managing the risk the vendor has accepted.

With T&M, you pay for the work as it is performed, so cost overruns are more likely to affect your budget directly. The US federal rules acknowledge that T&M contracts provide no positive profit incentive for the vendor to control costs or improve labour efficiency. They therefore require appropriate oversight and a ceiling price that the vendor exceeds at its own risk. For a founder, that means agreeing on a spending limit, reviewing progress regularly and retaining the ability to stop work before the budget runs out.

Research also challenges the idea that fixed-price contracts are always the more reliable option. Two studies by Jørgensen, Mohagheghi and Grimstad found that fixed-price contracts were associated with a higher risk of project failure than T&M contracts. Their findings pointed to factors including how vendors were selected and how involved customers remained during delivery. In a separate dataset of 785,325 small outsourced projects, Jørgensen found that failure risk increased when clients placed greater emphasis on low prices.

These findings do not prove that fixed price causes failure. They suggest that selecting a vendor primarily because its bid is cheapest can create problems regardless of the contract type. A low fixed-price quote may leave little room for uncertainty, while a low hourly rate can still produce a high final bill if the work takes longer than expected.

Research into IT services contracts helps explain why both models remain common. A study of 394 IT services contracts found that T&M arrangements were more likely when measuring quality after delivery was expensive and costs were difficult to estimate in advance. Research into offshore software projects also found that uncertainty about requirements, team size and resource shortages influenced contract choice. A follow-up study found that vendors earned more on average under T&M arrangements but could prefer fixed-price contracts for larger, longer projects with bigger teams.

The practical lesson is that the right contract depends on how well you understand the work before it begins. A vendor may be able to price a well-defined project confidently, but no contract can make uncertain requirements predictable.

Government procurement guidance follows a similar principle. The UK's Sourcing Playbook advises public buyers to avoid fixed-price payment mechanisms when the scope is not fixed. Its Model Services Contract guidance recommends linking T&M payments to milestones and moving away from T&M once the work is sufficiently defined. The US federal rules, in FAR 16.104, similarly warn that complex requirements and likely changes make costs harder to estimate in advance.

Agile delivery does not automatically rule out fixed price. Martin Fowler of Thoughtworks argues that fixed-price agile work is possible, but the arrangement cannot rely on an entirely fixed scope if requirements are expected to evolve. He also warns about vendors that deliberately underbid a fixed-price project and plan to make their profit through change requests. Thoughtworks has its own commercial perspective as a delivery provider, but the warning aligns with the broader procurement principle: an attractive initial price is not enough if the commercial terms make changes expensive.

The practical rule: use fixed price for small, clearly defined work that you can specify in detail before development starts. Consider capped T&M for work where you expect to learn as you build, but link payments to accepted increments and maintain control over spending.

Where risk leaks: acceptance, changes, milestones and IP

Whichever contract type you choose, four areas of the SOW can undermine the risk allocation you thought you had agreed to.

Acceptance written as "client sign-off". Acceptance is not just a courtesy. Under US federal procurement rules, acceptance acknowledges that the work conforms to the applicable contractual quality and quantity requirements. If your SOW says only "subject to client sign-off", without defining what satisfactory work looks like, either party can end up in a difficult position. You might withhold approval indefinitely because you disagree with the result, or the agreement might deem the work accepted if you miss a review deadline.

Published standard contracts commonly include deemed-acceptance provisions. Common Paper's Professional Services Agreement, for example, says the customer is deemed to have approved a deliverable if it does not reject it within the specified rejection period. Commercial sales law has a similar principle for goods: under UCC 2-606, acceptance can occur when a buyer fails to make an effective rejection after a reasonable opportunity to inspect. Whether particular software transactions are treated as sales of goods varies by jurisdiction.

The World Bank's information-systems procurement template also provides for acceptance following 60 consecutive days of production use. The lesson is to check the actual wording of your contract rather than assume that using the software or failing to respond has no contractual consequences.

Your SOW should specify measurable acceptance criteria, a reasonable review period, how defects must be reported and what happens when a deliverable fails testing. It should also distinguish defects that block acceptance from minor issues that can be fixed afterwards.

Change requests handled in chat. A message such as "Can we also add Google sign-in?" changes the agreed scope, but it does not automatically establish a new price, delivery date or formal approval.

Under fixed price, the vendor might absorb the extra work, reduce effort elsewhere or request additional payment. Under T&M, the extra work usually adds to your bill. In both cases, informal changes can create disputes about what was agreed.

Require a written change request that describes the proposed work, its cost and its effect on the schedule. Neither party should proceed until the authorised representatives have approved the change in writing.

Milestones tied to effort. A milestone such as "four weeks of development completed" rewards the passage of time rather than a usable result. US federal rules on performance-based payments explicitly state that the passage of time does not represent a meaningful effort or action for this purpose.

For a software project, tie payments to defined deliverables and agreed acceptance criteria. For example, a payment might become due when the registration flow passes the specified tests, rather than simply when the developer has spent four weeks working on it. This does not eliminate every payment dispute, but it gives both sides a clearer basis for deciding when an invoice is due.

IP that transfers only on final payment. If ownership of the software transfers only after the final invoice is paid, a dispute over that invoice could leave you relying on code you do not yet own. The exact legal position depends on the contract and governing law, so do not assume that paying for development automatically transfers copyright.

Your agreement should state who owns the deliverables, when ownership transfers, what happens to pre-existing code and third-party components, and how the vendor will hand over the source code and repository. The payment and intellectual-property sections of the SOW should work together rather than leave ownership dependent on an unclear final handover.

T&M projects also need an acceptance process at the sprint level, not just at the end of the entire project. The US General Services Administration's 18F digital services team recommended a quality surveillance plan requiring work to meet specific standards at the end of each sprint. The Scrum Guide makes a related point: work that does not meet the Definition of Done cannot be released or even presented at the Sprint Review.

Put a clear Definition of Done in your SOW and apply it to each sprint. That way, progress is measured by work that meets the agreed standard, not merely by hours consumed or tasks marked complete.

How do you write acceptance criteria a vendor can test?

Write each acceptance criterion so that a person or automated test can check it and reach the same yes-or-no answer you would. Avoid words such as "easy", "fast", "secure" or "works properly" unless you define exactly what they mean. The goal is to make it possible for both parties to agree whether the software meets the requirements without relying on personal opinion.

Acceptance criteria are essentially a checklist of outcomes that a deliverable must achieve before the customer accepts it. Each criterion should describe something observable and verifiable, rather than a general impression of quality.

A format that works

A practical format comes from behaviour-driven development (BDD), which describes software behaviour through scenarios using three steps:

• Given: describe the starting conditions.
• When: describe the action or event.
• Then: describe the expected result.

You do not need special software to use this format. It simply helps you turn a broad requirement into a test that someone else can repeat.

For example, "users can sign up easily" is open to interpretation. A testable version specifies the starting point, what the user does and what the system must do in response. The vendor can then test the behaviour, and you can verify the same result independently.

Vague criteria and their testable rewrites

The numbers in these examples are illustrative, not universal standards. Choose thresholds that suit your product and agree on them with the vendor before development begins. What matters is that each criterion specifies the starting conditions, the action and an outcome that another person can observe and verify.

The three settings that stop acceptance fights

Clear criteria are only half the acceptance clause. You also need a procedure for reviewing the work, reporting problems and deciding what happens next.

A fixed review window and a written reason for rejection. Specify how long you have to test each deliverable after receiving it. Published model agreements such as Bonterms use defined review periods, with some providing for acceptance if the customer does not reject the work within the deadline. They may also, like Common Paper's, require the customer to explain in writing which requirements the deliverable fails to meet.

Choose a review window your team can realistically meet. Decide who will test the software, when they will do it and how they will report the results. Put a reminder in the calendar as soon as a deliverable arrives.

Your SOW should also state what happens after a valid rejection. For example, the vendor might have to correct the identified defects and resubmit the deliverable for another test. Define the review process for resubmitted work so neither party has to guess whether the original deadline still applies.

A clear classification of defects. Without agreed defect categories, every bug can become an argument about whether the software is acceptable. Define which problems prevent acceptance and which can be corrected after delivery.

Two categories are often enough for a straightforward project:

• Blocking defects: problems that prevent an agreed acceptance scenario from passing, cause data loss or create a serious security vulnerability. The affected deliverable is rejected until the problem is fixed and retested.
• Minor defects: problems that do not prevent the agreed acceptance scenarios from passing or materially undermine the intended use of the software. The deliverable can be accepted, provided the vendor records the defect and fixes it within an agreed period.

Be specific about which category applies to each type of problem. A defect that looks minor to a developer might prevent a customer from completing an essential task. Your agreed acceptance criteria, not the vendor's preference, should determine whether the issue blocks acceptance.

Also distinguish defects from new features. If the software fails to meet an agreed requirement, correcting it is normally part of delivering the contracted work. If you request functionality that was never included in the scope, that may be a change request with an additional cost.

A defined test environment and test data. "Works on the vendor's laptop" is not an adequate acceptance standard. State where testing will take place, which devices and browsers are supported, what test data will be used and how the parties will handle problems caused by external services.

For example, if your application relies on a payment provider, specify whether acceptance testing will use its sandbox environment and test cards. Agree on what happens if that provider is unavailable during a test. A third-party outage should not automatically count as a software defect, but neither should it allow the vendor to claim that an untested feature has passed.

For each deliverable, the SOW should make three things clear: what will be tested, how success will be measured, and what happens if the test fails. When both parties agree on those details before development starts, acceptance becomes a repeatable process rather than a negotiation at the end of the project.

How should a change request work?

Every change should be requested in writing, priced by the vendor, and approved by you in writing before work begins. The vendor should explain how the change affects the total cost, delivery dates and acceptance criteria. Without that agreement, the original statement of work (SOW) remains in place.

Use a simple five-step process to keep changes from turning into disputes.

Two details make this procedure work in practice.

First, state explicitly that silence does not mean approval. If a change order has not been signed, it has not been approved, even if it has been sitting in your inbox for weeks. This prevents misunderstandings about whether a casual conversation or an unanswered email authorised extra work.

Second, keep a change log alongside the SOW. Every approved change should update the relevant deliverables, acceptance criteria, price and dates. Three months into a project, neither party should have to search through chat messages and emails to establish what was agreed.

Why does this matter? Requirements will change as you learn more about the product, but unmanaged changes can disrupt the schedule and budget. Research into software projects has found that continually shifting requirements can be particularly damaging, while another survey of 52 projects linked unstable requirements with a greater likelihood of finishing late and over budget. A 2018 Project Management Institute survey also reported that 52% of projects completed in the previous year had experienced scope creep or uncontrolled scope changes. That last figure comes from an industry practitioner survey, so it is useful context rather than a universal failure rate.

The evidence is not entirely one-sided. A separate study of 164 projects did not find that changing the scope during the project was correlated with project failure. The more important factor was whether requirements were understood and managed effectively.

That distinction matters: the goal is not to prevent change but to control its consequences. A change request should make the trade-off visible before you commit to it. You can then decide whether the added functionality is worth the extra cost, the delay or both.

The right process also depends on how much uncertainty the project involves. A fixed-price contract often begins with a defined scope, but an imperfect specification can lead to repeated change requests as the team discovers what the software actually needs. If you expect frequent changes, a capped time-and-materials arrangement may be more practical. Instead of repeatedly renegotiating a fixed price, you pay for agreed work within a spending limit and retain oversight of priorities.

The practical rule is simple: every change should have a clear description, an agreed price, a documented schedule impact and written approval before work starts. If you expect the scope to evolve constantly, reconsider the contract model rather than trying to solve every uncertainty with a longer SOW.

When should you pay, and when should you own the code?

Pay against accepted deliverables, not simply because time has passed, and make sure ownership of the code transfers as it is created or at agreed milestones. Otherwise, you could pay most of the project cost and still find yourself unable to access or legally own the software if a dispute arises before final payment.

Two things need to be clear in your SOW: what must happen before each payment is due, and when the intellectual property rights transfer to you.

Payments

The safest approach is to tie each invoice to a milestone that you can verify and accept. For example, you might pay when a working login system passes its agreed tests, rather than when the vendor says the login development phase is complete.

A modest deposit may be reasonable, particularly when the vendor needs to reserve developers or begin work before producing the first deliverable. After that, link payments to completed work that you can inspect. Each milestone should describe a result, such as a deployed feature that passes its acceptance tests, rather than an activity, such as completing a design phase.

Before signing, check that every milestone answers three questions:

• What exactly must the vendor deliver?
• How will you verify that it meets the agreed requirements?
• What must happen before the invoice becomes payable?

Time-and-materials contracts work differently because you typically pay for the hours worked. You can still retain control by setting a spending cap, requiring regular reports of the work completed and checking each sprint against an agreed Definition of Done. This means the team has a shared understanding of what must be completed and tested before work counts as finished.

The principle is the same under either pricing model: you should be able to verify what you are paying for. Do not rely on vague milestones or assume that a feature is complete simply because the vendor has spent the estimated hours on it.

Who owns the code

Do not assume that paying for software automatically makes you its legal owner. Copyright law differs by jurisdiction, and hiring an agency or an independent developer does not necessarily give you ownership of everything they create.

In the United States, a commissioned work does not automatically qualify as a work made for hire. That legal category applies only in specific circumstances. A written copyright assignment is often the more appropriate way to transfer ownership of custom software, and the transfer must be documented in a signed writing.

The UK has a similar requirement: a copyright assignment must be in writing and signed by or on behalf of the person transferring the rights. Although employers generally own copyright in work created by their employees as part of their employment, that rule does not automatically apply to independent contractors.

This distinction matters when you hire an agency or individual developers. Your contract should expressly state which intellectual property rights transfer to you, when the transfer happens and what happens to any pre-existing tools, libraries or components the vendor uses. If you are hiring individual contractors, also consider whether their employment or contractor status affects the arrangement.

Standard software-services agreements illustrate two common approaches. Common Paper's SOW template lets the parties choose between transferring ownership when the work is created and delaying the transfer until the associated fees have been paid. Both can be workable, but the timing matters.

Ownership that transfers only after you have paid the entire contract price creates a risk. If a dispute arises over the final invoice, you could have paid for most of the project but still lack ownership of the code you need to operate or continue developing it.

A more protective arrangement transfers ownership as the code is created or when the relevant milestone has been accepted and paid for. The contract should also require the vendor to provide the source code and repository history at each milestone, rather than holding everything back until the end.

Your SOW should distinguish between the custom code created for your project and any pre-existing software or third-party components. It should explain what you own outright and what you are licensed to use, including any conditions or limitations that could affect your ability to maintain, modify or distribute the product.

Before signing, have a lawyer familiar with the relevant jurisdiction review the intellectual property clause. The exact wording matters, and a generic template may not address the laws that apply to your contract.

The practical rule is straightforward: pay for work you can verify, document when ownership transfers, and ensure you receive the code and access needed to keep the project moving if the relationship ends.

Where RocketDevs fits

A fixed-scope statement of work is one way to buy software development. You define the deliverables, agree on what counts as finished and set the price and schedule in advance. The vendor takes on more of the estimation risk, while you need clear acceptance criteria and a formal process for approving changes. This approach works well when the requirements are understood and the work can be defined before development begins.

The alternative is to hire developers directly and manage the scope as the project evolves. That is where RocketDevs fits. Its vetted developers join your team, allowing you to adjust priorities from week to week without negotiating a new change request every time the requirements shift. You retain control over what gets built and when priorities change, rather than locking every detail into a fixed-price contract.

The trade-off is that this is a time-and-materials approach. You pay for the developer's time, so you carry more of the risk if the work takes longer than expected. You also need to manage the budget, set priorities, review progress and decide when to stop or change direction. A spending cap and regular visibility into the work help you keep that risk under control.

RocketDevs provides monitoring tools to support that oversight, including screenshots from both monitors every 3 minutes, keystroke and mouse-movement activity recorded per minute, and a centralized dashboard. Each developer is assessed over 6-8 hours, with only the top 2% of applicants accepted.

If your project has a stable scope and clearly defined deliverables, a fixed-price SOW may be the better fit. If you need flexibility to change priorities as you learn, a dedicated developer who works as part of your team may make more sense.

If you would rather manage the scope directly than repeatedly negotiate changes, build a vetted team with RocketDevs on a 14-day risk-free trial, money back and 100% honoured.

Conclusion: the bottom line

A statement of work should do more than describe what a developer will build. It should protect your budget, give you a reliable way to judge whether the work is finished, and make clear what happens when the plan changes. Define the deliverables, make acceptance measurable, tie payments to verified progress and secure ownership of the code as it is created. Most importantly, agree on how changes are priced and approved before the first line of code is written.

Then choose a contract that matches the work. If the scope is stable, a fixed-price SOW can give you greater cost certainty. If the requirements are likely to evolve, capped time and materials may give you the flexibility you need, provided you maintain visibility over spending and progress.

The real goal is not to predict every problem before development starts. It is to make sure neither side has to guess what happens when something changes. Get those rules right, and your SOW becomes more than paperwork: it becomes a practical framework for delivering software without losing control of the cost, the timeline or the code you are paying for.

Frequently asked questions

What should a statement of work include for software development?

A software development statement of work (SOW) should explain the project's purpose, list the deliverables and their acceptance criteria, set the schedule and price, define payment milestones, establish a change request process, and clarify who owns the code. It should also state the assumptions, dependencies and exclusions that could affect delivery. Include a maximum budget or spending cap where appropriate, so you know your financial exposure before work begins.

Who writes the statement of work: the client or the vendor?

Either party can draft it. In many private projects, the vendor provides a template, which can be a useful starting point. However, you should review the acceptance criteria, change control, payment terms and intellectual property clauses carefully before signing. Make sure the document protects your interests as well as the vendor's, rather than accepting its standard wording without question.

What is the difference between a statement of work and a contract?

A statement of work is often one part of a larger contract. The master services agreement establishes the general legal terms, while the SOW describes the specific project, including its deliverables, schedule, price and acceptance requirements. If the two documents contradict each other, the contract's precedence clause determines which terms take priority. Check this clause before signing, especially if the SOW changes anything agreed in the master agreement.

What happens if the project scope changes after signing?

Changes should follow the procedure set out in your SOW. Typically, the vendor describes the proposed change, estimates its additional cost and explains how it will affect the delivery schedule. Both parties then approve the change in writing before work begins, and the SOW is updated to reflect the new requirements, price and dates. A conversation or email discussion alone may not constitute formal approval under your contract, so follow the agreed process.

How can you protect your budget when hiring a software developer?

Choose a pricing model that matches how clearly you can define the work. A fixed-price contract can provide greater cost certainty when the scope is well understood, while time and materials can offer more flexibility when requirements are likely to evolve. For time-and-materials work, set a spending cap, require regular progress and cost reports, and review completed work against agreed criteria. Whichever model you choose, tie payments to verifiable progress wherever possible and make sure you understand what happens if the budget or timeline needs to change.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• US Federal Acquisition Regulation, 2.101 Definitions, acquisition.gov, FAC 2026-01
• US Federal Acquisition Regulation, 37.602 Performance work statement
• US Federal Acquisition Regulation, 16.202-1 Firm-fixed-price contracts
• US Federal Acquisition Regulation, 16.601 Time-and-materials contracts
• US Federal Acquisition Regulation, 16.104 Factors in selecting contract types
• US Federal Acquisition Regulation, 16.103 Negotiating contract type
• US Federal Acquisition Regulation, 46.501 Acceptance
• US Federal Acquisition Regulation, 32.1004 Procedures
• US Department of Defense, MIL-HDBK-245D, Handbook for Preparation of Statement of Work, 1996
• US Digital Service, TechFAR Handbook
• 18F, US General Services Administration, De-risking custom technology projects, 2019
• Crown Commercial Service, Digital Outcomes 6 statement of work template
• UK Cabinet Office, Model Services Contract buyer guidance v2.2(A), 2025
• HM Government, The Sourcing Playbook, version 4, 2023
• HM Government, The Digital, Data and Technology Playbook, version 2, 2023
• UK Cabinet Office, Contracting for Agile guidance note, 2023
• Government Digital Service, Writing user stories, GOV.UK Service Manual
• European Parliament and Council, Directive 2014/24/EU on public procurement, Article 42
• World Bank, Standard Procurement Document: Information Systems, June 2020
• Common Paper, Professional Services Agreement standard terms v1.1 and SOW template
• Bonterms, Professional Services Agreement v1.2
• 17 U.S.C. 101 and 17 U.S.C. 204, via Cornell Legal Information Institute
• US Copyright Office, Circular 30: Works Made for Hire
• Uniform Commercial Code 2-606, via Cornell Legal Information Institute
• Copyright, Designs and Patents Act 1988, section 90 and section 11, legislation.gov.uk
• Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2020
• Dan North, Introducing BDD, 2006
• Cucumber, Gherkin reference
• Daniel Méndez Fernández, Stefan Wagner and co-authors, Naming the pain in requirements engineering, Empirical Software Engineering, 2017
• June Verner, Karl Cox, Steven Bleistein and Narciso Cerpa, Requirements engineering and software project success, Australasian Journal of Information Systems, 2005
• Tracy Hall, Sarah Beecham and Austen Rainer, Requirements problems in twelve software companies, IEE Proceedings - Software, 2002
• Didar Zowghi and Nur Nurmuliani, A study of the impact of requirements volatility on software project performance, APSEC, 2002
• Project Management Institute, Pulse of the Profession 2018
• Magne Jørgensen, Parastoo Mohagheghi and Stein Grimstad, Direct and indirect connections between type of contract and software project outcome, International Journal of Project Management, 2017
• Magne Jørgensen, Failure factors of small software projects at a global outsourcing marketplace, Journal of Systems and Software, 2014 (author copy)
• Alexander Kalnins and Kyle J. Mayer, Relationships and hybrid contracts: an analysis of contract choice in information technology, Journal of Law, Economics, and Organization, 2004
• Anandasivam Gopal, Konduru Sivaramakrishnan, M. S. Krishnan and Tridas Mukhopadhyay, Contracts in offshore software development: an empirical analysis, Management Science, 2003
• Anandasivam Gopal and Konduru Sivaramakrishnan, On vendor preferences for contract types in offshore software projects, Information Systems Research, 2008
• Bent Flyvbjerg, Alexander Budzier and co-authors, The empirical reality of IT project cost overruns, Journal of Management Information Systems, 2022
• J. Laurenz Eveleens and Chris Verhoef, The rise and fall of the Chaos report figures, IEEE Software, 2010
• Magne Jørgensen and Kjetil Moløkken-Østvold, How large are software cost overruns? A review of the 1994 CHAOS report, Information and Software Technology, 2006
• Martin Fowler, Fixed Price, 2003, and Fixed Scope Mirage, 2004
• Wikipedia, Statement of work