Feature

How to Choose the Right Project Document and Define the Work Clearly

By Devon Ariza · 4 August 2026

The short answer: scope defines the work; the statement covers the engagement

In common commercial usage, a scope of work defines what must be done and delivered, including the work’s boundaries, inclusions, and exclusions. A statement of work usually documents the broader project arrangement: the scope plus the responsibilities, schedule, pricing, acceptance process, governance, and change terms needed to manage the engagement.

The two documents often work together. The statement of work may contain a clearly labeled scope-of-work section or incorporate a separate scope exhibit. For a straightforward internal initiative, however, a focused scope may stand alone because budgets, approvals, responsibilities, and operating rules are already established elsewhere. This broader-versus-focused distinction is a common commercial convention, reflected in Asana’s comparison of scope and statement documents, but it is not universal.

Some organizations use the terms interchangeably. Others assign them different meanings according to their procurement process, industry, project-management framework, or contract templates. The practical question is therefore not merely, “What is this document called?” It is, “Where are the work, commercial commitments, approval rules, and change authority actually documented?”

Point of comparison	Scope of work	Statement of work
Primary purpose	Defines the work to be performed and its boundaries	Defines the broader project engagement
Typical contents	Tasks, activities, deliverables, inclusions, exclusions, assumptions, dependencies, milestones, and execution details	Objectives, scope, responsibilities, schedule, pricing, payment, reporting, acceptance, governance, changes, and approvals
Primary audience	Project managers, delivery teams, reviewers, and operational stakeholders	Clients, vendors, project leads, procurement, finance, legal, and approvers
Timing	May be prepared during planning, solicitation, or project setup, depending on the organization	Commonly prepared before a specific engagement begins, though procurement practices vary
Commercial terms	May omit them or refer to terms documented elsewhere	Commonly addresses fees, expenses, invoicing, and payment treatment
Acceptance	Should identify what acceptable work or deliverables look like	Commonly establishes the wider review, rejection, correction, and approval process
Change control	Establishes the baseline against which a request can be assessed	Commonly states who may request and authorize changes and how impacts are documented
Approvals	May identify operational reviewers	Commonly identifies project and commercial approval authority
Relationship to a contract	May be incorporated into an agreement and acquire contractual effect	May be a standalone agreement or a project-specific exhibit under another agreement

The final row describes common structures rather than automatic legal outcomes. Whether either document has contractual effect depends on how it is written, approved, executed, and incorporated into the surrounding agreement set, as explained in this overview of statements of work and related contract documents.

A complication is that statement of work and scope of work are both commonly abbreviated SOW. Atlassian expressly notes this shared acronym while distinguishing the broader statement from the focused scope. To avoid confusion, spell out the term on first use and define it in the document—for example, “Project Statement of Work” and “Scope Exhibit”—rather than assuming capitalization or context will settle the meaning. See Atlassian’s explanation of the shared SOW abbreviation.

Before relying on either label, check:

Your organization’s approved templates and glossary
Procurement policies and solicitation rules
The master or governing agreement
Industry-specific usage
Client or supplier documentation requirements
Any order-of-precedence provision controlling conflicts

The title is a useful signpost. The contents and governing rules are what make the document usable.

Why the terminology changes across commercial work and public procurement

Reputable sources disagree because they are often describing different operating environments.

In the common commercial model, the statement of work is the broader, project-specific document. It explains the engagement’s objectives and conditions and contains or incorporates the scope of work, which describes execution in greater detail. This model is common in consulting, agency, technology, and other client-vendor relationships.

Public procurement can use a different, stage-based model. NIGP’s professional guidance says the terms have historically been used inconsistently or contradictorily. In its public-procurement framing, a scope of work is directed to potential suppliers during solicitation and communicates the procuring entity’s needs and desired outcomes. A statement of work is shaped by the procurement method and the parties’ agreement after supplier selection, then communicates performance expectations and deliverables to the selected supplier. That distinction is set out in NIGP’s public-procurement guidance on scope and statement documents.

This does not mean the NIGP definition controls a private agency agreement, consulting engagement, or internal project. It is a professional convention designed for public procurement. A private company may instead use “statement of work” for the signed client-vendor project document and “scope of work” for the work-definition section inside it.

Other environments add further variation:

Consulting teams may use “statement of work” for the client-approved project document containing services, fees, responsibilities, and terms.
Research institutions may use “scope of work” for the portion of an agreement that defines research tasks, reports, deliverables, and dates.
Project-management teams may distinguish an external vendor document from an internal project scope statement.
Contracting teams may treat either document as an exhibit governed by a master agreement.
Procurement teams may assign different names according to whether the document supports solicitation, evaluation, award, or contract administration.

A project scope statement should not automatically be treated as another name for a vendor-facing scope of work. The project scope statement may be an internal planning artifact that describes the project’s boundaries and deliverables for the project team. A vendor-facing scope may cover only the outsourced portion and may be written for pricing, performance, and acceptance. A long-running professional community discussion illustrates how practitioners use these terms differently across project management, consulting, and vendor settings, but its comments are individual interpretations rather than an official current standard.

The safest response is to create an organization-specific naming convention. For example:

Project Statement of Work: the project-level commercial and operational document
Scope Exhibit: the detailed work definition
Project Scope Statement: the internal planning baseline
Change Order: the approved record of a change to the baseline

Place those definitions near the beginning of the governing document. Avoid using “SOW” by itself in filenames, approval emails, purchase requests, or change discussions when two interpretations are possible.

What belongs in a statement of work

A statement of work is a project-specific document that commonly combines four kinds of information:

Work definition: what will be performed and delivered
Commercial treatment: how the work is priced, invoiced, and paid
Operating rules: who does what, when decisions are due, and how the parties communicate
Governance and approval: how outputs, changes, and completion are authorized

A useful drafting structure follows.

Project background. Briefly explain the situation that led to the engagement. Include enough context to make the requirements understandable without turning the section into a general company history.
Objectives. State why the project exists and what business or operational result it is intended to support. Objectives provide direction; they are not substitutes for deliverables. “Support the product launch” is an objective, while an approved launch plan is a deliverable.
Scope of work. Define the tasks, activities, deliverables, methods where relevant, boundaries, inclusions, exclusions, assumptions, and dependencies. This may appear in the main document or an attached exhibit.
Deliverables. Identify the concrete outputs to be submitted, such as a report, campaign plan, configured system, approved design, training session, or data file. Each deliverable should have an owner, due point, format, reviewer, and acceptance method.
Schedule and milestones. State the project period, key dates, dependencies, review windows, and checkpoints. Distinguish a milestone such as “design review completed” from the associated deliverable.
Roles and responsibilities. Assign ownership for work, decisions, approvals, access, assets, data, and communications. Include client responsibilities as well as supplier responsibilities; otherwise, dependencies controlled by the client can disappear into the background.
Work location. If location affects staffing, access, security, travel, equipment, or expenses, specify where the work will occur and whether activities are remote or on-site.
Reporting and administration. Define status meetings, progress reports, time records, risk reporting, escalation routes, and communication cadence. These obligations support delivery but should not be confused with substantive project outputs.
Pricing and payment. State the pricing model, fees, approved expenses, invoice timing, taxes where applicable, and payment triggers. Payment might be associated with dates, recorded effort, milestones, or accepted deliverables, depending on the engagement.
Acceptance. Explain who reviews each output, what standards apply, how long the reviewer has to respond, what happens if an output is rejected, and how resubmission works. Acceptance criteria translate a general expectation into an observable approval decision.
Assumptions and constraints. Record the conditions on which the plan, price, staffing, or schedule depends. Constraints may include fixed dates, approved systems, security requirements, budget limits, or restricted working hours.
Change procedure. Define how a change is requested, assessed, approved, documented, and added to the project baseline. Identify authorized approvers rather than allowing any participant to make an informal commitment.
Approvals. Provide the applicable sign-off or execution mechanism and identify the parties or roles authorized to approve the document.

Colorado State University’s procurement guidance similarly separates objectives, scope, schedule, deliverables, acceptance, assumptions, pricing, and project-management details. It also emphasizes that acceptance criteria should support objective evaluation. See its guidance for developing a statement of work.

A statement of work can be structured as a standalone project agreement. It can also operate as a project-specific exhibit under a master service agreement, or MSA. In the latter structure, the MSA may contain relationship-level provisions while the statement addresses one defined project. Whether the statement forms the entire agreement, an incorporated exhibit, or an operational document depends on its wording and the rest of the contract set—not merely its title. Thomson Reuters’ statement-of-work explainer describes this common distinction between the relationship-level role of an MSA and the project-specific role of a statement of work.

There is no universal page count or template. A short, low-risk engagement might need a concise document, while a multiparty implementation with phased acceptance and material financial exposure may need substantially more detail. Draft for the project’s complexity, delivery model, risk, and approval needs.

The work requirements may also use different approaches:

Design-based requirements prescribe how work must be performed or a product must be made.
Performance-based requirements emphasize measurable results while giving the supplier more flexibility over method.
Level-of-effort requirements emphasize time, capacity, or resources rather than a single finished result.

Ohio government procurement guidance describes these as common statement-of-work approaches, including performance-based requirements that focus on outcomes rather than prescribed processes. They are useful classifications, not a universal or exhaustive taxonomy. See the Ohio guide to writing clear and effective statements of work.

The right approach depends on what the buyer can define and evaluate. Prescribing the method may be appropriate where compatibility, safety, or process consistency matters. Focusing on performance can preserve supplier flexibility. Level-of-effort treatment can suit advisory work where the exact output cannot be fully determined in advance, but it needs controls for time, reporting, priorities, and authorization.

What belongs in a scope of work

A scope of work is the focused description of what the delivery team will do and where that work stops. It commonly covers tasks, activities, deliverables, boundaries, inclusions, exclusions, assumptions, dependencies, milestones, timelines, resources, and execution requirements.

A practical scope outline includes:

Problem or need: What condition is the project intended to address?
Goal: What broad result should the work support?
Measurable objectives: What should be knowable or demonstrable by the end?
Task breakdown: What activities will each responsible party perform?
Deliverables: What concrete outputs will those tasks produce?
Boundaries and inclusions: Which teams, systems, channels, markets, phases, or formats are covered?
Exclusions: What plausible work is specifically outside the baseline?
Assumptions and dependencies: Which inputs, decisions, access, assets, and approvals are expected?
Administrative requirements: Which meetings, reports, calls, records, or progress updates are required?
Timeline: When are tasks, outputs, reviews, and dependencies due?

These concepts should remain distinct:

Scope describes the work and its boundaries.
Tasks are the activities performed.
Deliverables are the concrete outputs or completed results.
Milestones are checkpoints used to track progress.
Acceptance criteria determine whether a deliverable is approved.

A deliverable should connect an activity to a specific end product. Vague verbs such as “support,” “improve,” “assist,” and “optimize” describe intent but rarely establish what completion looks like. New York University’s scope-writing guidance recommends measurable tasks, quantifiable outputs, explicit timelines, and deliverables that combine a task with an end product. See NYU’s guidelines for writing a scope of work.

For example, replace:

Improve campaign reporting.

With an illustrative bounded requirement:

Deliver five dashboards using the data sources listed in Appendix A by the agreed delivery date. The campaign analytics lead will review the dashboards against the documented field, calculation, and refresh checks and provide one consolidated response within the stated review period.

The number of dashboards is an example, not a general standard. The stronger language works because it identifies an output, quantity, input boundary, reviewer, evaluation basis, and response process.

Exclusions matter because readers fill gaps with assumptions. If a scope includes social campaign creative, a reasonable stakeholder might assume that source files, additional channels, paid-media setup, creator contracting, localization, photography, or post-campaign optimization are included. An exclusions section makes clear which plausible adjacent activities were not included in the plan or price.

An exclusion should be specific enough to be useful. “Anything not listed is excluded” can supplement a well-written scope, but it does not replace explicit treatment of foreseeable ambiguities. Name the work most likely to be assumed.

Assumptions and dependencies also need operational consequences. Instead of writing, “Client will provide data,” state:

Which data is required
In what format it must be supplied
Who is responsible for providing it
The required date
What validation is expected
Who assesses the impact if the data is missing, incomplete, or late
Whether schedule, cost, staffing, or acceptance dates may need revision

An assumption is not a solution to a failed dependency. The document should explain how the parties will assess and record the consequence if the assumed condition proves false.

When to use a standalone scope, a full statement, or both

Choose the document structure by examining the engagement, not by applying a title mechanically. Ask:

Is an external party performing the work?
Are fees, expenses, invoices, or payment milestones involved?
Is the work subject to formal procurement?
Would a misunderstanding create material operational, financial, regulatory, or reputational risk?
Are several stakeholders responsible for inputs or approvals?
Is acceptance complex or phased?
Are changes likely enough to require controlled evaluation?
Do other agreements already govern commercial and legal terms?

A standalone scope may be sufficient for a low-risk internal initiative where the organization already governs staffing, budgets, approvals, and change decisions. Even then, the scope should identify objectives, owners, deliverables, dates, dependencies, exclusions, and completion criteria.

A fuller statement of work is generally more suitable when an engagement involves an external supplier, material commercial commitments, substantial risk, several approval layers, complex acceptance, or payment linked to delivery. The statement can document responsibilities, pricing, payment, reporting, governance, and change procedures in addition to defining the work.

For a typical client-vendor engagement, use both functions: a broader statement of work with a clearly labeled scope section or attached scope exhibit. This structure keeps the detailed execution baseline visible while connecting it to the project’s commercial and operating rules.

Consider four scenarios.

Internal reporting project. An analytics team is creating a dashboard for another department. Existing internal policies already establish staffing, budget authority, and escalation. A concise scope may be enough if it defines the data sources, dashboard outputs, owners, review date, exclusions, and completion checks.

Agency campaign. A brand hires an agency for a multichannel campaign. The work involves creative outputs, client-supplied assets, review rounds, publishing dates, fees, expenses, usage questions, and approval dependencies. A broader statement with a detailed scope is more appropriate than a task list alone.

Consulting engagement. A consultant will conduct interviews, facilitate workshops, and deliver recommendations. The statement can address fees, invoicing, scheduling, responsibilities, confidentiality references, approval, and changes. The scope can specify the number and format of workshops, interview responsibilities, report contents, and excluded implementation work.

Public solicitation. Under NIGP’s stage-based public-procurement distinction, a solicitation-stage scope communicates the public entity’s needs and desired outcomes to potential suppliers. After selection, a statement of work can express the agreed performance expectations and deliverables for the chosen supplier. That model should be applied within its public-procurement context, not assumed to control private contracts.

Document titles remain secondary to coverage. A document called “Scope of Work” may contain project-specific commercial terms and be incorporated into an agreement. Conversely, a document called “Statement of Work” can still be incomplete if it says little about payment, acceptance, dependencies, or change authority.

As a rule of thumb, if the team must document not only what will be done, but also who pays, who approves, how changes occur, and which obligations govern, a narrow scope alone may not cover the full engagement.

A worked example: from project objective to accepted deliverable

Consider a hypothetical creator-marketing campaign between a brand and an agency. This example illustrates document functions; it does not imply that Larping Agency offers contract drafting, procurement, or legal-review services.

At the statement level, the objective might be:

Plan and launch a creator campaign during the agreed project period to support awareness and qualified traffic for the brand’s new product line.

The broader statement could then establish:

Project start and end dates
Brand and agency responsibilities
Pricing structure and approved expenses
Invoice timing and any payment triggers
Weekly reporting cadence
Brand approval roles and response periods
Escalation contacts
Change-request procedure
Relationship to the governing agreement
Final project approval

The scope section would translate that arrangement into execution. It might specify:

Creator research and outreach
Candidate-screening requirements
Creator briefing
Content quantities and required formats
Review rounds
Publishing coordination
Tracking requirements
Campaign reporting outputs
Included platforms and markets
Excluded paid-media management, extended licensing, travel, localization, or post-campaign services

One work chain can be mapped precisely:

Task: Review candidate creators against the agreed audience, content, suitability, and availability fields.
Deliverable: A completed candidate shortlist containing the required information.
Milestone: Shortlist submitted to the named brand reviewer.
Acceptance: The shortlist contains all agreed fields, covers the required candidate criteria, and receives written approval from the authorized reviewer.
Payment trigger: Any payment associated with shortlist acceptance applies only if the executed agreement actually creates that trigger.

This chain prevents “creator research” from operating as an undefined block of effort. It connects activity to output, timing, review, and—where the agreement provides for it—commercial treatment.

Now suppose the baseline includes short-form video and static images, but the brand later requests an additional long-form video format. The agency should not automatically accept or reject the request. The first question is whether the requested format falls within the documented baseline.

If it is not included, the parties can assess:

Additional creator fees
Production and editing effort
Revised briefing requirements
New technical specifications
Schedule effects
Review and acceptance implications
Usage or distribution needs
Effects on invoicing or payment milestones

A practical change workflow is:

The requester submits the proposed change in writing.
The delivery lead compares it with the approved scope baseline.
The appropriate parties assess cost, schedule, resources, dependencies, acceptance, and payment effects.
An authorized decision-maker approves, rejects, or modifies the proposal.
The parties record an approved change in the required amendment or change-order form.
The project team updates the scope, schedule, budget, responsibilities, and acceptance baseline.

The baseline is what makes that conversation possible. Without it, “additional format” becomes a debate about memory and expectation. With it, the team can compare the request against documented quantities, formats, responsibilities, and exclusions.

Nothing in this hypothetical example establishes mandatory clauses, quantities, prices, payment events, or legal consequences. Those depend on the actual parties, agreement, procurement rules, and applicable law.

How to draft requirements that can be reviewed and accepted

Good requirements allow a reader who did not participate in the original discussions to understand what must happen, who owns it, and how completion will be determined.

Use precise language where precision matters. Include:

Quantities or ranges
File or delivery formats
Responsible parties
Required inputs
Due dates or triggering events
Review periods
Revision treatment
Objective acceptance criteria

Define acronyms, specialist terminology, and unusual measurements. A delivery team may understand “GA4 event taxonomy,” “raw cut,” or “UAT,” but a finance approver or procurement reviewer may not. A glossary is particularly useful when a term affects scope, pricing, or acceptance.

For every deliverable, answer seven questions:

What is the output?
Who produces it?
When is it due?
In what format is it delivered?
Who reviews it?
How is acceptance determined?
What happens after approval, rejection, or no response?

Separate project outputs from administrative obligations. A campaign report may be a substantive deliverable. Weekly status calls, time records, risk logs, and progress emails are administrative requirements. Both can matter, but mixing them makes it harder to see what the supplier is actually producing.

Explicitly exclude plausible but unpriced work. Depending on the project, examples could include:

Additional channels or markets
Editable source files
Revisions beyond an included allowance
Third-party integrations
Travel
Rush delivery
Data cleanup
Localization
Training
Post-launch support

These are example categories, not a universal exclusions checklist. Include what a reasonable reader might otherwise assume is part of the particular project.

Assign client inputs and dependencies with the same care applied to supplier tasks. Identify who provides decisions, brand assets, system access, data, subject-matter experts, approvals, and consolidated feedback. Do not implicitly make the supplier responsible for an input another party controls.

Acceptance criteria should use observable standards. Phrases such as “professional,” “best in class,” “user-friendly,” or “high quality” may express an aspiration, but they are difficult to apply consistently unless the document defines how those characteristics will be evaluated. Instead, refer to an approved brief, documented fields, technical specifications, required tests, named examples, or other observable checks.

Before signing or approving the document, perform an ambiguity audit:

Are important terms or acronyms undefined?
Do dates conflict across the scope, schedule, and payment sections?
Does every task, input, and approval have an owner?
Are foreseeable exclusions missing?
Can the acceptance criteria actually be tested or observed?
Are assumptions paired with dependencies and a response process?
Is it clear what triggers an invoice or payment?
Does the document identify who may request and approve changes?
Are review deadlines and revision procedures stated?
Do the statement and attached scope use the same quantities and terminology?

Review should be collaborative but role-specific. Project and delivery teams should test whether the work can be performed. Procurement should check supplier and process requirements. Finance should examine pricing, expenses, invoices, and payment mechanics. Legal stakeholders should review contractual risk where appropriate. Operational owners should confirm that they can provide the promised inputs and approvals.

Collaboration does not mean every stakeholder rewrites every clause. It means the relevant owner verifies the part of the engagement that falls within their responsibility.

Legal effect, related documents, and the final review

Neither “statement of work” nor “scope of work” determines legal effect by itself. The wording, signatures, incorporation into other agreements, governing documents, authority of the parties, and applicable law may all matter. A scope may become part of the parties’ contractual obligations when incorporated into an executed agreement. A statement may operate as an exhibit governed by another contract rather than as the overarching agreement. Thomson Reuters’ legal-publisher guidance likewise distinguishes a project-specific statement of work from an MSA and explains that statement-of-work structure varies with the engagement.

A common—but non-universal—document map looks like this:

Master service agreement: Establishes relationship-level terms that may govern multiple projects.
Statement of work: Addresses a particular project or engagement.
Scope section or exhibit: Defines the tasks, outputs, boundaries, and execution requirements.
Service-level agreement: May establish measurable service standards, service windows, or response targets.
Purchase order: May authorize purchasing or reference commercial details, depending on the organization’s process.
Change order or amendment: Records an authorized change to the approved baseline.
Acceptance record: Documents approval, rejection, testing, or completion under the agreed process.

An RFP, or request for proposal, generally serves a different function. It is associated with soliciting supplier proposals rather than documenting final project-specific obligations in the same way as a statement of work. Information from an RFP may inform the resulting agreement, but the documents should not automatically be treated as interchangeable.

Do not assume that an MSA always overrides a statement, or that a purchase order, service-level agreement, scope exhibit, or change order always occupies a fixed position in the hierarchy. Review the governing documents for an order-of-precedence clause or another conflict rule. If two provisions differ, resolve the issue under the applicable agreement rather than relying on a generic document diagram.

Before work begins, ask:

Which document controls if provisions conflict?
Is every incorporated attachment correctly named and attached?
Who has authority to approve the initial work and later changes?
Are assumptions connected to a process for handling failure or delay?
Do acceptance criteria, invoice timing, and payment mechanics align?
Are termination, transition, and unfinished-work consequences addressed where needed?
Is every use of “SOW” expanded and defined?
Do the scope, schedule, price, and responsibilities describe the same baseline?

Obtain qualified legal advice when the documentation raises questions about enforceability, liability, intellectual property, confidentiality, termination, regulatory duties, indemnities, or substantial financial exposure. This article provides general educational guidance and is not legal advice.

Ultimately, the choice in statement of work vs scope of work should return to function rather than labels. Define the work precisely in a scope. Add the commercial, governance, acceptance, responsibility, and change terms the engagement requires. State how the documents relate, expand ambiguous acronyms, confirm the applicable organizational or procurement definition, and align every deliverable with a reviewable acceptance process.

Frequently asked questions

Is a scope of work always part of a statement of work?

No. In the common commercial structure, the scope of work often appears as a section or exhibit within a broader statement of work. A focused scope can also stand alone for a simple or internal project when responsibilities, budgets, approvals, and operating rules are already governed elsewhere.

The appropriate structure depends on the organization, engagement, and governing documents. If a scope stands alone, verify that the project still addresses any necessary pricing, acceptance, responsibilities, dependencies, approvals, and change procedures.

Are a statement of work and a scope of work legally binding?

Either may have contractual effect, but neither title makes that result automatic. Legal effect can depend on the document’s language, signatures, incorporation into another agreement, the parties’ authority, governing documents, and applicable law.

A scope incorporated into an executed agreement may form part of the parties’ contractual obligations. A statement of work may be a standalone agreement or an exhibit under an MSA. The surrounding structure, rather than the title alone, determines the document’s intended role, as reflected in Deskera’s overview of statements of work and related contract documents. Seek qualified legal advice for a specific engagement when enforceability or material exposure is involved.

Can both statement of work and scope of work be abbreviated SOW?

Yes. Both terms are commonly abbreviated SOW, which creates avoidable ambiguity. Spell out the intended term, define it, and use distinct names such as “Project Statement of Work” and “Scope Exhibit.” Apply those names consistently in the document, filenames, purchase records, approvals, and change orders.

What is the difference between scope, tasks, deliverables, milestones, and acceptance criteria?

Scope defines the work and its boundaries. Tasks are the activities performed within that scope. Deliverables are the concrete outputs or completed results produced by those activities. Milestones are checkpoints that mark progress or important events. Acceptance criteria establish how a reviewer will determine whether a deliverable is approved.

For example, conducting candidate research is a task; a completed candidate shortlist is a deliverable; shortlist submission is a milestone; and the required data fields plus reviewer approval form the acceptance criteria.

How does public procurement distinguish a scope of work from a statement of work?

Under NIGP’s public-procurement framing, a scope of work communicates an entity’s needs and desired outcomes to potential suppliers during solicitation. A statement of work is shaped by the selected procurement method and the parties’ agreement, then directed to the selected supplier to define performance expectations and deliverables.

That is a context-specific public-procurement distinction. Private companies and other organizations may use the terms differently, so teams should follow the definitions, templates, and rules governing their particular engagement.