Project scope defines the work you will deliver, its boundaries and the conditions for calling it complete. For a freelancer, that means agreeing quantities, formats, revisions, responsibilities and approval before starting. A request such as “I need materials to promote my service” can then become a set of decisions both you and your client can check.
This guide provides a reusable template, completed fictional examples, criteria for distinguishing corrections from additional work and a change record. It also shows how to clarify vague requests and adapt project scope to writing, websites and recurring assistance.
Tudum Tip:
When to define project scope
Define the scope after understanding the need and before committing to a deliverable, fee and deadline. If you still lack the audience, objective or source materials, return to the client brief for freelancers with questions and a template. Use the brief to gather information; scope selects the work you will do with it. Your proposal presents the solution and its commercial terms.
You can combine these parts in one document if each decision remains clear. However, this planning template does not replace a review of contractual terms, usage rights or obligations that apply to the engagement. Those depend on the service and location involved.
Asana’s guide to project scope covers boundaries, objectives and deliverables. This article applies that idea to a small freelance service, adding practical fields for approval, revision rounds and changes.
Define project scope when the client is still unsure
Start with the decision the deliverable needs to support. If a client asks for “a complete website”, ask who will use it, what action visitors must be able to take and which materials already exist. Then separate the first release from ideas that can wait. An exploratory conversation should not become a commitment to features nobody has defined.
Use these questions in your discussion and record who needs to confirm each answer.
- Which specific problem needs solving now, and for whom.
- What is the smallest useful deliverable that meets that need.
- Which inputs are ready, and which still require research, production or access.
- What time, capacity and budget constraints guide the decision.
- Who decides when members of the client’s team disagree.
- How both parties will check whether the deliverable meets the agreement.
Assumptions and decisions in project scope
Next, label each point as confirmed, assumed or awaiting a decision. For example, “the client will supply five testimonials” remains an assumption until someone confirms their availability and permission to use them. Record the owner and response date. If an unresolved point changes the page count or the feasibility of an integration, make that uncertainty visible in your estimate.
When uncertainty is substantial, suggest a discovery stage with its own deliverable: requirements, access checks and a set of options. Agree the work and terms for that stage separately. Afterwards, both parties can define the implementation scope using better information. Do not imply that investigation automatically includes building the solution.
The distinction between boundaries, milestones and constraints also appears in Atlassian’s guide to boundaries and deliverables. The approach below adapts those ideas to small independent services; it is an organisational suggestion rather than a universal contracting rule.
Describe deliverables that people can check
“Create content” leaves too much open. Try “Design one PDF of up to six pages using the client’s supplied text and images”. Then specify the final format, dimensions, intended channel and who provides each input. A concrete description makes later requests easier to assess.
- Quantity and unit. Distinguish three individual designs from three campaigns.
- Specifications. Include dimensions, length, language and required versions.
- Final files. Agree whether delivery includes only a PDF or also editable files.
- Acceptance criteria. Explain the checks used to approve the deliverable.
- Relevant exclusions. Identify adjacent services the client might otherwise assume are included.
A useful criterion can be checked by the person receiving the work: the PDF opens, follows the approved sequence and contains the supplied contact details. “Make it amazing” does not provide the same test. Avoid promising sales, reach or a financial return as acceptance criteria for work that does not control those outcomes.
Agree revisions, inputs and timing
A revision round can mean one consolidated set of comments from the approver on the same version. Define that in the project scope rather than simply promising “two changes”. Explain whether the round covers adjustments within the chosen direction and how you will assess a new direction, format or deliverable.
Distinguish a correction needed to meet the agreement from a new request. Fixing a phone number that you entered incorrectly is different from adding a new service to the PDF. Check what happened against the agreed record; do not treat every correction as an extra.
Also agree who provides text, images and access, when these are due and what condition they must be in. If inputs are incomplete, record the gap before starting dependent work. You can make the schedule begin after complete inputs are checked and the start is confirmed, provided that condition is explicit and agreed.
Choose a review period and one person to consolidate feedback. If feedback arrives late, reassess your availability and confirm a revised date. Do not assume silence means approval or that deadlines automatically move under a rule the client has never agreed to.
A project scope template to reuse
Replace the bracketed fields and remove anything irrelevant. Before sending, look for vague words such as “complete”, “unlimited” or “as needed”. If they remain, explain the specific boundary they represent.
Identification. [Project name, document version, date and responsible people.]
Objective and audience. [The need being addressed and who will use the deliverable.]
Included deliverables. [Quantity, format, dimensions, language, files and delivery channel.]
Out of scope. [Services, versions or stages that are not included.]
Inputs and dependencies. [What each party provides, due dates and conditions for starting.]
Stages and dates. [Conditional start, first version, feedback and final delivery. Define working days and time zones where relevant.]
Revisions. [Number of rounds, what a round means and the boundaries of included adjustments.]
Approval. [Approver, checkable acceptance criteria and confirmation channel.]
Changes. [How to record a request, assess its impact and confirm the revised scope before doing it.]
Related terms. [Reference to the proposal and documents covering fees, payment and other terms.]
A completed fictional project scope example
This fictional example demonstrates the template. An independent service provider wants a PDF to send to prospective clients. The name and timings are illustrative; they do not describe a project completed by Tudum.
Project. Horizon Workshop service presentation, version 1, 23 October 2026. Freelancer responsible for layout; client responsible for content and approval.
Objective. Organise the service presentation for prospective clients to read digitally.
Included. One English-language PDF, portrait A4, up to six pages and one visual direction. Final PDF delivered in a shared folder.
Excluded. Copywriting, logo creation, photography, printing, translation, social media designs and editable source files.
Inputs. Client supplies final copy of up to 900 words, a logo and up to eight images they are entitled to use. Freelancer checks availability and technical suitability before confirming the start.
Stages. First version within five working days of complete inputs and confirmed start. Client returns consolidated feedback within two working days; revised delivery within two working days of that feedback. Calendar dates will be confirmed at the start.
Revisions. Two consolidated feedback rounds covering layout adjustments within the approved direction and six-page limit. Content changes affecting the structure require assessment before work starts.
Approval. Client checks that the file opens, the page limit is met, approved content and contact details are present, and the sequence and text are readable. Approval is recorded by email.
Changes. Requests outside these boundaries require an assessment of work, timing and any additional fee, followed by written confirmation before proceeding. Fees and payment sit in the related proposal.
Tudum Tip:
How to assess a request outside the scope
Suppose the client requests another language version and three social media images. Existing source files do not remove the need for new deliverables, adaptations and checks. To keep project scope clear, compare the request with the approved list, then offer a decision before starting the extra work.
- Record the specific request and the date it arrived.
- Classify it as a correction, included revision or scope change, explaining why.
- Identify additional stages, dependencies and impact on the current delivery.
- Offer options, such as adding work, replacing a deliverable or moving it to a later phase.
- Confirm the deadline, any fee and the revised scope version before doing the change.
Adapt this example response: “Our agreement includes one English-language PDF. Another language version and social images are new deliverables. I’ll assess the required inputs and send the timing and fee impact so you can decide before we begin.”
If you choose to absorb a small adjustment, record that exception and its limits. A one-off gesture should not look like a permanent expansion. Asana’s explanation of scope management provides further context for recording and managing changes.
Classify requests against the project scope
Before calling a request extra work, compare it with the approved version and establish why it arose. The apparent size of the edit does not settle the question. A single word might correct your mistake, while a small button might require a new integration. These fictional situations show how to assess the difference.
A mismatch with the approved material
The PDF contains a phone number that differs from the supplied text. Here, the output does not match an approved input. Record the correction and check the other contact details. Do not automatically count this failure as a preference revision or treat it as an additional deliverable.
An adjustment within the agreed direction
The client asks for larger headings and different positions for two images, keeping the six pages and approved visual direction. If an available revision round covers these adjustments, collect the comments and revise that version. Afterwards, return a list of changes so completed requests do not reappear without context.
A new deliverable or direction
The client changes the audience, requests a different structure and adds a print version. Those decisions and checks go beyond the agreed digital PDF. Explain the differences, estimate their impact and offer options. However, first check whether an ambiguity in your own scope caused the misunderstanding, rather than assigning all responsibility to the client.
If the distinction remains unclear, identify the wording that allowed two interpretations. Agree a practical resolution and clarify that boundary in the next version. Scope management should support collaboration instead of becoming an automatic rejection of any dissatisfaction.
Clear approval criteria help with this assessment. Atlassian’s explanation of acceptance criteria describes testable conditions for completion. Here, use that principle to check the agreed output rather than promising commercial results you cannot control.
Record a change to project scope
A message buried in a conversation may not show what was approved. Therefore, keep a short change record linked to the current scope version. Separate an estimate under discussion from a decision that both parties have confirmed.
Fictional record M-01. Horizon Workshop project, linked to scope version 1.
Request. Add three social media images based on the PDF. The client still needs to confirm dimensions and final copy.
Assessment. Three additional files require layout adaptation, export and checking. The PDF remains six pages long.
Options. Keep the PDF alone; commission the images later; or include them now with revised timing and fees.
Condition for starting. Confirm the option, inputs, fees and new dates in writing. Until then, the request remains under review and the additional work does not start.
Update. If approved, issue version 2 with the three images, formats, acceptance criteria and confirmed schedule. Keep version 1 as part of the history.
Check effort, scheduling and confirmation
To estimate impact, list the extra tasks and dependencies. In this example, that means adapting layouts, receiving copy, exporting files and reviewing them. Production effort differs from calendar time: your availability and the client’s feedback must also fit the schedule. Do not simply add “one more day” without checking those dependencies.
You could reply: “I can assess the three images. First, I need the formats confirmed and the final copy supplied. I will then send the timing and fee options. The PDF follows our current agreement; the additional images will start after your confirmation.” If the decision also affects the PDF, identify which stage must wait.
Finally, summarise what was approved and what remains excluded. After a meeting, record the decision in the agreed channel and request confirmation. The new version becomes the working reference, while previous versions remain available. Do not rely on an unnoticed edit to communicate a changed commitment.
Project scope examples for other services
The following fictional examples show how to adapt the same fields. Quantities, revision rounds and timings are illustrative choices, not market standards. Use limits appropriate to the actual work and place commercial terms in the related document.
Article writing
Deliverable. Two English articles of approximately 800–1,000 words each, with approved topics and audiences. Includes public-source research, headings and one consolidated revision round per article. Excludes interviews, images, website publication and translation.
Inputs and acceptance. The client supplies brand guidance and approves the topics before writing begins. Checks cover alignment with the topic, clarity, identified sources and no invented information. Confirm delivery and feedback dates in the calendar. Adding an interview requires preparation, scheduling, permission and writing time; it involves more than inserting a few sentences.
A small business website
Deliverable. Four pages — home, services, about and contact — on an agreed platform, using client-supplied copy and images. Includes adaptation to agreed screen sizes and a form with predefined fields and recipient. Excludes e-commerce, a private area, additional languages and ongoing maintenance.
Inputs and acceptance. The client provides the required domain, hosting and access through an agreed secure method. Approval checks cover navigation, readability on the agreed devices and form delivery to the correct recipient. Assign responsibility for launch, migration and licences explicitly. Where data handling or specialist accessibility requirements apply, define the necessary work and review; a simple form test does not establish full compliance.
Recurring virtual assistance
Deliverable. Organise up to 40 spreadsheet records per week, with two weekly update windows. Includes checking supplied fields and producing a list of missing information. Excludes urgent support, financial analysis and decisions on the client’s behalf.
Capacity and priorities. The client supplies data before the agreed window and names a contact for questions. When 55 records arrive, the extra 15 do not silently join the workload. Decide whether to defer them, replace another task or expand the service. Also agree what happens to unused capacity; do not assume it carries into the following month.
For recurring work, specify when a service period closes and how the next renewal will be assessed. This keeps a weekly limit distinct from permanent availability. Reassess capacity when the task mix changes: 40 complete records may require different effort from 40 incomplete records needing follow-up.
For a platform-specific comparison, Fiverr’s guidance on service packages shows how packages can combine different boundaries, revisions and extras. Those platform conditions do not automatically apply to direct client work or to the examples in this guide.
Write checkable boundaries into project scope
- “A complete website”. List the pages, features, integrations and tests. Otherwise, each party may picture a different project.
- “Two changes”. Define two consolidated feedback rounds, what they cover and who submits them. Avoid inventing a counting method after comments arrive across several messages.
- “Delivery in five days”. Specify working or calendar days, the starting event and dependencies. Then confirm actual dates.
- “Adjustments until it is right”. Agree the direction, acceptance criteria and handling of new requests. A preference change and a technical failure need different discussions.
- “Support included”. Specify the subject, channel, duration and availability, distinguishing delivery corrections from future maintenance.
Before closing the project, deliver a checklist with the files. Identify versions, outstanding points and the approval channel, and clarify what happens to access and materials after the service ends. If there is disagreement, record the specific issue and next action instead of declaring everything accepted or rejected without criteria.
Check your project scope before sending it
- The client can identify every deliverable and the relevant exclusions.
- Formats, quantities and files are described.
- Input dependencies appear before firm timing commitments.
- There is an approver and a clear definition of a revision round.
- Acceptance criteria support an actual delivery check.
- New requests have an assessment and confirmation process.
- The document has a version and matches the related proposal.
Use project scope to support a clear conversation
Choose a real service, fill in the template and discuss the boundaries with your client. Then keep the confirmed version accessible during the work. Both of you should be able to consult the same agreement when a question, approval or new idea appears.
For other steps in independent work, explore the guide to professions and entrepreneurship and our Professions and Entrepreneurship articles.
References
- Asana. Project scope and how to define it. Accessed 23 October 2026.
- Asana. Scope management plan. Accessed 23 October 2026.
- Atlassian. Goals, deliverables and boundaries. Accessed 23 October 2026.
- Atlassian. Acceptance criteria. Accessed 23 October 2026.
- Fiverr. Creating and managing Gig packages. Accessed 23 October 2026.
