What is Project Scope?

What Belongs in Project Scope

A complete scope document answers six questions:

• What are the deliverables? — list every specific output the project will produce
• What features/functions are included? — for each deliverable, what does 'complete' mean?
• What is explicitly excluded? — the out-of-scope list prevents 'but I assumed...' disputes
• What are the acceptance criteria? — how will stakeholders know each deliverable is done?
• What are the constraints? — budget, timeline, technology, regulatory limitations
• What assumptions are we making? — things assumed true that, if false, would change the scope

Scope vs Requirements

Scope and requirements are related but distinct:

Requirements describe what the deliverable must do — functional and non-functional attributes. "The website must load in under 3 seconds" is a requirement.

Scope defines what work will be done and what won't. "We will build a 5-page website; a blog section is out of scope" is scope.

Requirements define the quality of what's in scope. Scope defines the boundary of what's included. Both need to be documented; conflating them creates confusion.

The Scope Baseline and Change Control

Once the project sponsor approves the scope, it becomes the scope baseline — the reference point against which all changes are measured. Any request that adds to, removes from, or changes the baseline is a scope change and should go through a formal change control process.

Change control doesn't mean saying no to every change. It means evaluating the impact (cost, time, quality), getting explicit approval from the right stakeholder, and updating the project plan accordingly.

For agencies: the scope baseline is what you're billing against. If scope increases without a change order, you're absorbing the extra work. Track actual hours against scope to catch this early.

Writing a Scope Statement: Template

A scope statement doesn't need to be a formal document. For most agency projects, a well-structured section in your project proposal or SOW is enough — as long as it covers the right elements.

The key is specificity. 'A professional website' is not scope. 'A 7-page WordPress website with a contact form and Google Analytics integration, mobile-responsive, delivered in English only' is scope.

Scope Validation: Getting Client Sign-Off

Defining scope is only half the job. Getting the client to explicitly confirm and sign off on that scope is what protects you when disagreements arise later.

Scope validation is the formal process of reviewing the scope statement with the client and getting their written agreement. Walk through the in-scope and out-of-scope lists together at kickoff. Ask the client to confirm their understanding of each item.

Three elements make scope validation stick. First, the out-of-scope list matters as much as the in-scope list. Clients understand what's included; they're surprised by what isn't. Second, get confirmation in writing. Third, link scope validation to the payment schedule — in many agency contracts, the first payment milestone triggers only after signed scope confirmation.

If a client resists scope validation ('I trust you, let's just get started'), that's a yellow flag. Projects that skip scope validation at the start disproportionately produce scope disputes at the end.

• Review both in-scope and out-of-scope lists explicitly with the client at kickoff
• Ask for written confirmation — email thread minimum, signed document preferred
• Walk through the out-of-scope section item by item — surprises happen here, not in-scope
• Link the first payment milestone to signed scope confirmation when possible

Out-of-Scope Examples That Agencies Miss

Most scope disputes don't happen because the client asked for something radically new. They happen because something that seemed obvious wasn't written down.

Content creation. Agencies scope design and development but assume the client will provide all copy, images, and video. Write it explicitly: 'Copywriting, photography, and video production are out of scope. Client provides all content by [date].'

Revision rounds beyond the agreed number. Define the number of revision rounds per phase. 'Up to two rounds of revisions on each design page; requests constituting a change in direction are billed as additional work.'

Migration and data transfer. If you're redesigning a website, does the scope include migrating content from the old site? This is a significant amount of work frequently assumed by the client and not quoted by the agency.

Post-launch support. Define the support window: '30 days of bug fixing post-launch is included; general support and new feature requests after 30 days are billed at the standard hourly rate.'

• Content creation: always out of scope unless explicitly included
• Revision rounds: define the number per phase; extra rounds are change requests
• Content migration from old sites: frequently assumed in, rarely scoped
• Post-launch support: define the window and what happens after