How to scope a client project from a brief

Most projects don't go wrong during execution. They go wrong in the first hour — when a brief is read quickly, assumptions are left unspoken, and someone sends a price before anyone has defined what "done" means. Scoping is the discipline that prevents that. Done well, it takes an unstructured brief and produces something you can quote, schedule, staff, and defend when the client asks for "one small change."

Here is the process we recommend to freelancers, consultants, and small agencies.

1. Separate what the brief says from what it assumes

Read the brief once for comprehension, then read it again with a highlighter. You are looking for three different kinds of statements:

• Facts — dates, budgets, page counts, platforms, named stakeholders.
• Requests — what the client is explicitly asking you to produce.
• Assumptions — things implied but never stated: that copy will be provided, that there is one round of revisions, that brand assets exist, that legal review is somebody else's job.

The assumptions are where scope creep lives. Every one you surface now is an argument you don't have to have in week six.

2. Convert requests into deliverables with acceptance criteria

A request is "we need a new website." A deliverable is "a five-page responsive marketing site, built on the client's existing CMS, with content migrated from the current site." Add an acceptance criterion so completion isn't a matter of opinion: "approved by the marketing lead on staging, passing Lighthouse ≥ 90 on mobile."

If you cannot describe how a deliverable will be signed off, it isn't scoped yet — it's still a hope.

3. Break deliverables into tasks small enough to estimate

The right size for a task is one that a single person can finish in a day or less. Anything larger hides uncertainty. As you decompose, tag each task with:

• the role that owns it (designer, developer, strategist, PM, client)
• the phase it belongs to (discovery, design, build, QA, launch)
• a time estimate in hours
• any dependency that has to land first

This is the point where scoping stops being writing and becomes structure. It is also the slowest part to do by hand, which is why so many quotes are built on a gut number instead. Strumap exists for exactly this step: upload the brief as a PDF and it extracts the actionable work, assigns roles, estimates effort, and lays the tasks out on a timeline, so you start from a draft plan instead of a blank page.

4. Price the plan, not the vibe

Once you have a task list with hours and roles, your quote almost writes itself: sum the hours per role, apply your rates, then add a contingency band that reflects genuine unknowns rather than nerves. Two things are worth doing explicitly:

• Show the shape, not every line. Clients want to see phases and outcomes, not 84 tasks.
• Name what's excluded. A short "not included" list — content writing, translations, third-party licences, post-launch support — is the cheapest insurance in professional services.

5. Sanity-check the calendar before you commit

An estimate in hours is not a schedule. Lay the tasks against real availability: your other clients, the client's review cycles, holidays, and the fact that approvals routinely take three days rather than one. If the deadline only works when every dependency lands perfectly, say so in writing and propose which deliverable moves if it slips.

6. Write the scope down and get it agreed

Your scope document should fit on two pages: objective, deliverables with acceptance criteria, phases and milestones, assumptions, exclusions, change-request process, and price. The change-request clause matters most — define what triggers one, how it's estimated, and who can approve it. With that in place, new requests become a normal commercial conversation instead of a conflict.

A checklist you can reuse

• Objective stated in one sentence, in the client's language
• Every deliverable has an acceptance criterion
• Tasks are one day or smaller, with role, phase, estimate, dependency
• Assumptions and exclusions written down
• Client responsibilities (content, access, approvals) listed with dates
• Contingency and change-request process agreed
• Schedule validated against real availability

FAQ

How long should scoping take?

For a project of a few weeks, budget two to four focused hours. For anything longer, treat discovery as a small paid engagement of its own — you are producing the artefact the whole project depends on.

What if the brief is too vague to scope?

Scope the discovery instead. Sell a short, fixed-price phase whose deliverable is the scope document, then quote the build once you know what you're building.

How much contingency should I add?

Ten to fifteen percent for familiar work with a known client, twenty-five percent or more when the technology, stakeholders, or requirements are new to you. Show it as a named line rather than padding individual tasks.

Can AI do the scoping for me?

It can do the mechanical half well: pulling tasks out of a brief, suggesting roles, estimating effort, spotting missing dependencies. The judgement — what to exclude, what to charge, which risk you're willing to carry — stays yours. Starting from a generated draft simply means you spend your hour on the judgement instead of the typing.

---

Ready to try it on a real brief? Get started with Strumap and turn your next client document into a scoped task plan.