What a written project scope should include, and why you should insist on one
By Vorenda. Published
A written scope is the page that says what you are buying. It lists what will be built, what will not, who provides what and by when, and what happens when the plan changes. Ask for it before any work starts. It protects you, and it protects the people doing the work.
What is a project scope?
A project scope is a written description of the work. It names the goal, the things you will receive, the stages, the dates and the rules for changing the plan. Some people call it a statement of work. Think of it as the page both sides can point to when memory fails.
It is easy to mix up with two other documents. This table shows the difference.
| Document | What it does | Who relies on it |
|---|---|---|
| Proposal | Explains why you should hire this team and roughly what they will do | You, while you decide |
| Scope (statement of work) | Describes exactly what will be built, by when, and how changes work | Both sides, during the project |
| Contract | Makes the agreement legally binding | Both sides, if there is a dispute |
The scope often sits inside the contract as an attachment, so one page carries the detail and the other carries the legal weight.
Why should you insist on a written scope?
Because most project problems start as an assumption nobody wrote down. Here is a small example. You ask for a website with a quote form. You picture a form that asks for drawings, quantities and a deadline. The developer pictures a name, an email address and a message box. Neither of you is wrong. A written scope is where that gap shows up, while it still costs nothing to fix.
There are two more reasons.
- You can compare quotes. A price only means something if you know what it buys. A quote without a scope is a number with no meaning.
- Changes become choices. Every project changes. With a scope, a change is a visible decision with a known effect on cost and dates. Without one, it is an argument.
What should a written scope include?
A good scope has eleven parts. Each one answers a question that otherwise comes up in the middle of the project.
- The goal. One or two sentences on what the project is for. Everything else is judged against it.
- The deliverables. What you will receive, named exactly. A quoting tool your estimators use every day is a deliverable. Better efficiency is not.
- What is not included. The list people skip, and the one that prevents the most surprises.
- The stages and the dates. Each stage has an end and a date. Dates that depend on you say so.
- What you provide, and by when. Photos, specifications, logins, decisions and feedback. A project slows down when the client side is left out.
- Who approves what. Name the person who says yes at the end of each stage.
- Rounds of revisions. How many rounds of changes each stage includes, and what happens after.
- How changes are handled. A change goes in writing, with its effect on cost and dates known before anyone builds it.
- Handover and ownership. What you receive at the end, such as files, source code and accounts, and when ownership passes to you.
- Payments. When each payment is due, tied to stages and not to a calendar guess.
- Assumptions. The facts the plan depends on, such as the content being ready by the start of stage two.
What does a written scope look like in practice?
Here is a short example for a quote-request website for a machine shop. The shop and its details are invented, to show the shape of a scope.
- Goal: Let buyers see what the shop can make and send a complete quote request.
- Deliverables: A home page, six capability pages, a quote form that asks for drawings, quantity, material and deadline, and a contact page.
- Not included: Online payments, customer logins, photography, and writing the capability pages from scratch. The shop supplies the specifications.
- Stages: Plan and page structure, design, build, launch. Each ends on a date written in the scope.
- You provide: Specifications for each capability, photos of the shop floor, the logo file, and one person who approves each stage.
- Revisions: Three rounds of changes per stage.
- Changes: Anything outside this list goes through a written change request, with its effect on cost and dates.
- Handover: All files, the site's code, and the hosting and domain accounts in the shop's name, once the invoices are paid.
- Payments: An advance, then one payment when each stage is approved.
- Assumptions: The shop sends the specifications before the design stage begins.
A small project can fit on one page. A larger one may take a few. The test is clarity, not length.
How do you check a scope before you sign?
Read it in this order. Each step takes a minute and can save weeks.
- Read the list of what is not included first. If it is empty, ask for it. Every project has things it does not cover.
- Check that each deliverable can be recognized. You should be able to look at the finished work and say yes or no.
- Check which dates depend on you. If a date assumes you reply the same day, say so now.
- Ask what done means for each stage. The answer should be something you can see, not a feeling.
- Find the change process. It should say that you see the effect on cost and dates before the work is built.
- Confirm what you own at the end. Files, source code, domain names and accounts should all be named.
What happens when the project changes?
It will. A new idea appears, a supplier changes, a deadline moves. That is normal, and a scope is how you handle it calmly.
A good process has three steps. The change is written down. The developer says what it does to cost and dates before building anything. You approve it or you do not. Nothing happens by surprise.
What if a developer says you do not need a scope?
For a very small job, a one-page scope is enough. For anything larger, a developer who will not write down what they are building is asking you to trust a total price with no detail behind it. Treat that as a warning sign. Our guide to choosing a website developer lists others.
Where Vorenda fits
Vorenda is a design and engineering studio. We agree a written scope before work starts, every project is priced on its own, and you approve the direction before the real work begins. You own the files, the source code and the accounts once the invoices are paid. If the project is software your team will use every day, read about custom business software development, or write to info@vorenda.com.
Questions
Is a scope the same as a contract?
No. A scope describes the work. A contract makes the agreement binding. The scope is usually part of the contract, as an attached statement of work.
How long should a scope be?
As long as it needs to be to be clear. A small project may take a page. A larger one may take a few. If you cannot read it in one sitting, it is probably too vague or too heavy.
Who writes the scope, me or the developer?
Usually the developer drafts it after talking with you. You review it, correct anything that is wrong and approve it. Both sides should be able to point to the same page.
What is the difference between a scope and a quote?
A quote gives a price. A scope says what the price buys. A quote without a scope is a number with no meaning.
Related
Custom business software development: We build web apps and business software around how you work: orders, quotes, jobs and reports. For businesses in Canada, the USA, Europe, India and beyond.