How to Define Project Scope

Project scope defines the boundary of a project.

It establishes:

• What the project is expected to achieve
• Which work is included
• Which work is excluded
• Which requirements must be satisfied
• Which assumptions support the estimate
• Which constraints limit delivery
• Which dependencies affect progress
• Who makes decisions
• What marks completion

A clear project scope does not guarantee that nothing will change. It gives both parties a shared baseline from which they can evaluate change.

Without that baseline, additional requests, revised assumptions, customer delays, technical discoveries, and new stakeholder expectations become difficult to distinguish from the original obligation.

What Is Project Scope?

Project scope is the complete boundary of the work required to produce an agreed project result under defined conditions.

It covers more than the final outputs.

A useful scope describes:

The U.S. Federal Acquisition Regulation provides a useful formal example. Its current work-statement rules say a performance work statement should describe required results using measurable standards and should address purpose, scope or mission, performance period, background, objectives, and operating constraints. Private solopreneur projects rarely need the same level of procurement formality, but these elements form a practical scope structure.

Project Scope vs. Deliverables

A deliverable is an output the provider agrees to supply.

Project scope defines the complete obligation surrounding that output.

For example:

Deliverable: A redesigned ecommerce website.

The scope must still explain:

• Number and types of pages
• Supported devices and browsers
• Existing content to be migrated
• Ecommerce functions included
• Integrations covered
• Customer-supplied materials
• Testing responsibilities
• Training and handover
• Work explicitly excluded

The deliverable names the output. The scope defines the work and conditions required to produce it.

Project Scope vs. Requirements

Requirements describe the characteristics, capabilities, or standards the result must satisfy.

Examples include:

• Users must be able to reset their passwords.
• Images must be delivered at a specified resolution.
• The report must cover the agreed markets.
• The system must support five user roles.
• The installation must meet an applicable safety standard.

Requirements sit inside the project scope.

The scope also includes the work needed to satisfy them, the limits around that work, and the assumptions on which the commitment depends.

Project Scope vs. Project Plan

Scope defines what the project contains.

The project plan defines how the work will be organized and completed.

A project plan may include:

• Sequence
• Schedule
• Resources
• Communication
• Risk controls
• Review points
• Tools
• Work assignments

The plan may change while the scope remains stable.

For example, a provider may change the order in which pages are written without changing the agreed pages, quality, or delivery result.

Project Scope vs. Statement of Work

A statement of work is the document used to record the project obligation.

Project scope is one of its central components.

A statement of work may also contain:

• Commercial terms
• Payment schedule
• Legal provisions
• Confidentiality
• Intellectual-property terms
• Cancellation conditions
• Liability provisions

The scope describes the work boundary. The statement of work records that boundary within the wider agreement.

Why Project Scope Matters More in a One-Person Business

A larger company may absorb an unexpected task by redistributing work across several employees.

A solopreneur has less internal spare capacity.

An additional ten hours can displace:

• Another customer project
• Sales activity
• Administration
• Time off
• Product development
• Support obligations

The effect is rarely limited to one project.

Unplanned work can create delays across the entire business.

A useful scope therefore protects:

• Customer expectations
• Delivery quality
• Profitability
• Calendar capacity
• Other customer commitments
• The owner’s working limits

Current project research shows why boundaries must account for more than a task list. In PMI’s 2026 survey, 81% of project professionals said projects had become more complex, and 31% of complex projects failed to achieve the full scope of their intended benefits. Projects that managed complexity effectively reported an 88% success rate, compared with 14% among teams that managed it only slightly effectively or ineffectively. These PMI findings concern organizational projects rather than solo client engagements, but they highlight the importance of identifying dependencies, stakeholders, interfaces, and changing conditions instead of treating scope as a simple checklist.

The Main Dimensions of Project Scope

A project boundary can expand through several independent dimensions.

“Small additions” across several dimensions can create a substantial total change.

A request for one extra page may appear minor until it also introduces:

• A new customer segment
• A new integration
• Another reviewer
• A shorter deadline
• Additional compliance requirements

Scope should therefore be evaluated as a system rather than only by counting deliverables.

How to Define Project Scope Step by Step

1. Define the project purpose

State why the project exists.

The purpose should describe the business or practical reason for doing the work.

Examples:

• Prepare a product catalogue for migration to a new platform.
• Create the core website needed for a professional-services launch.
• Establish a reliable monthly reporting workflow.
• Produce approved photographs for a new product range.

The purpose helps resolve later decisions.

When a proposed task does not contribute to the purpose, it may belong outside the project.

2. Define the project objective

The objective describes what must be true when the project is complete.

A useful objective is:

• Specific
• Observable
• Relevant
• Bounded
• Substantially influenced by the project

Example:

Configure and hand over a customer-onboarding workflow that captures signed agreements, invoices the initial payment, collects required intake data, and creates the internal project record.

This is stronger than:

Improve customer onboarding.

PMI’s newer definition of project success emphasizes value rather than completion alone. Its 2025 global research classified only half of projects as successful when success meant delivering value that justified the effort and expense for key stakeholders. Thirteen percent failed and 37% only partly produced the expected result. The PMI study supports defining project scope around a useful result rather than treating the completion of planned activity as sufficient.

3. Identify the unit of scope

Choose units that reflect the quantity of work.

Possible units include:

• Pages
• Products
• Records
• Interviews
• Sessions
• Locations
• Accounts
• Users
• Campaigns
• Languages
• Systems
• Data sources
• Minutes of finished media

A project may require several units.

Example:

The project covers one website, one language, up to 50 page templates, three external integrations, and one customer database containing up to 20,000 valid records.

Choose units that can be verified before delivery begins.

“Medium-sized website” is difficult to price and manage. “Up to 50 page templates and 5,000 content entries” is clearer.

4. Divide the work into work packages

A work package is a manageable group of related work with a recognizable output or completion point.

A website project might contain:

1. Discovery and input review
2. Information architecture
3. Page design
4. Development
5. Content migration
6. Integration
7. Testing
8. Training and handover

Breaking the scope into packages helps reveal work that a high-level description hides.

ISO 21511 provides guidance for work breakdown structures across projects of different sizes, sectors, and levels of complexity. Its WBS guidance treats the breakdown structure as a way to organize the project’s complete content and connect it with planning and control.

A practical work-package description includes:

• Purpose
• Included work
• Required inputs
• Output
• Owner
• Estimate
• Dependency
• Completion condition

Do not break the project into hundreds of tiny tasks before the major boundary is understood.

5. List all included work

Write the work the provider agrees to perform.

Use action-based statements.

Examples:

• Review the supplied analytics data.
• Interview up to three named stakeholders.
• Configure the approved fields and workflow.
• Import the validated customer records.
• Test the agreed user journeys.
• Deliver one training session.
• Transfer administrator access.

Included work should account for supporting activity such as:

• Preparation
• Communication
• Quality review
• Project administration
• Handover

These activities consume capacity even when they do not appear in the final output.

6. State exclusions explicitly

Exclusions identify related work that the project does not cover.

Common exclusions include:

• Copywriting
• Development
• Data cleaning
• Translation
• Travel
• Printing
• Photography
• Legal review
• Ongoing maintenance
• Third-party charges
• Work on unsupported systems
• Additional stakeholder workshops
• Implementation after strategy delivery

An exclusion is most useful when a customer might reasonably assume the work is included.

For example:

The migration includes valid product records supplied in the agreed template. The project does not include correcting, translating, or manually reconstructing incomplete product data.

Avoid relying on “anything not listed is excluded” as the only boundary. State the likely areas of confusion directly.

7. Record planning assumptions

An assumption is a condition treated as true when estimating the project, even though it is not yet fully verified.

Examples include:

• The existing data export is complete.
• The customer owns the required source files.
• One authorized reviewer will provide feedback.
• The current software supports the documented integration.
• The supplied content will not change after approval.
• Work can be performed remotely.
• No regulatory approval is required.

Assumptions should be:

• Visible
• Testable where possible
• Assigned to an owner
• Verified by a deadline
• Connected to a consequence

Use an assumption table:

An assumption that proves false does not automatically become free additional work.

The effect on scope, schedule, and price should be assessed.

8. Identify constraints

A constraint is a fixed or limiting condition within which the project must operate.

Common constraints include:

• Budget
• Deadline
• Available technology
• Existing brand system
• Regulatory rules
• Staff availability
• Working hours
• Location
• Security requirements
• Approved suppliers
• Hardware
• Platform limitations

Example:

The system must use the customer’s existing CRM plan and cannot require an enterprise upgrade.

Constraints shape what can be promised.

If a customer fixes the budget and deadline, the scope may need to remain flexible. If the result and deadline are fixed, the budget or resources may need to change.

Avoid treating scope, time, cost, and quality as independently fixed when the project does not have enough capacity to satisfy all four.

9. Map dependencies

A dependency is something the work relies on.

Dependencies may be:

Customer dependencies

• Access
• Data
• Approvals
• Feedback
• Decisions
• Product samples
• Internal staff availability

Provider dependencies

• Specialist contractor
• Equipment
• Research
• Software
• Prior work package
• Quality review

External dependencies

• Platform uptime
• API availability
• Shipping
• Regulatory decision
• Supplier delivery
• Third-party licence
• Weather
• Venue access

Record for each dependency:

• What is required
• Who controls it
• When it is needed
• How delay affects the project
• Whether an alternative exists

A project should not promise an unconditional delivery date when a critical dependency remains controlled by another party.

10. Map interfaces

An interface is a point where different parts of the project meet.

Examples include:

• Provider and customer
• Design and development
• Website and payment processor
• CRM and email platform
• Photographer and printer
• Consultant and internal implementation team
• Two contractors
• New software and legacy data

Interfaces create hidden work involving:

• Coordination
• File conversion
• Testing
• Approval
• Error handling
• Responsibility disputes

For each interface, define:

• Input
• Output
• Format
• Owner
• Handover point
• Failure responsibility

A solopreneur may control their own work while having limited control over the system into which that work must fit.

11. Assign roles and decision rights

State who:

• Supplies inputs
• Performs work
• Reviews work
• Approves decisions
• Consolidates feedback
• Pays invoices
• Accepts completion
• Authorizes changes

A simple responsibility table may be enough:

A stakeholder who may comment is not necessarily a stakeholder who may change the scope.

Name one person or role with final authority where possible.

12. Define communication scope

Meetings and messages are work.

Define:

• Number of meetings
• Duration
• Participants
• Communication channel
• Normal response time
• Feedback format
• Availability period
• Emergency handling

Example:

The project includes one 60-minute kickoff meeting, two 30-minute progress reviews, and asynchronous communication by email with responses within two working days.

Without a communication boundary, a fixed-scope project can become an open-ended advisory relationship.

13. Define review and approval points

Decide which work requires approval before later work begins.

Examples include:

• Research findings before strategy
• Wireframes before design
• Design before development
• Data sample before full import
• Prototype before manufacturing
• Outline before full writing

Approval points reduce the cost of changing an earlier decision after dependent work has been completed.

State:

• What is reviewed
• Who approves it
• Review deadline
• Available revision
• Effect of delayed approval
• Effect of changing an approved decision

Not every internal task needs customer approval. Excessive approval points can slow the project and transfer ordinary provider decisions back to the customer.

14. Define completion

A project should have an explicit closing condition.

Completion may require:

• Delivery of all approved outputs
• Completion of agreed testing
• Transfer of files and access
• Completion of included corrections
• Customer acceptance
• Expiration of the review period
• Payment of the final invoice
• End of the included support period

Distinguish among:

• Work complete: the provider has finished the agreed work.
• Deliverables accepted: the customer has accepted the outputs.
• Project closed: files, access, invoices, and administrative obligations are complete.
• Benefits realized: the customer has achieved the wider value expected from using the result.

The new ISO 21513:2026 standard separates post-project evaluation from ordinary project closure by focusing on objectives, actual outcomes, and benefits. This evaluation guidance reinforces an important boundary: a provider can complete the agreed project scope without controlling every later business benefit.

Define Fixed and Flexible Scope

Not every part of a project must be fixed.

A useful scope can separate stable commitments from controlled flexibility.

Fixed elements

These do not change without a formal decision.

Examples:

• Project objective
• Maximum budget
• Final deadline
• Supported systems
• Required compliance standard
• Core deliverable

Flexible elements

These may be adjusted within a stated boundary.

Examples:

• Order of work
• Exact recommendations
• Distribution of hours
• Selection of features from a prioritized list
• Number of iterations within a timebox
• Content chosen for a fixed production capacity

Example:

The engagement includes 40 hours of implementation during August. Work will be selected from the agreed priority backlog. Completion of every backlog item is not guaranteed.

This is a valid flexible scope because the capacity and selection process are defined.

It is not the same as promising an unlimited result within 40 hours.

Fixed-Scope Projects

A fixed-scope project works best when:

• Required outputs are known.
• Inputs can be inspected in advance.
• Complexity is reasonably predictable.
• Customer responsibilities are clear.
• Acceptance can be tested.
• Dependencies are manageable.

The provider usually carries more estimation risk.

Use a risk allowance where uncertainty remains.

Timeboxed Projects

A timeboxed project fixes the available period or capacity while allowing the completed work to vary.

Examples include:

• Five consulting days
• A two-week technical sprint
• Twenty hours of implementation
• A one-day workshop

A timebox should define:

• Available capacity
• Priority order
• Work-selection authority
• Progress reporting
• Items not guaranteed
• Treatment of unused time

Discovery Projects

A discovery project is appropriate when the delivery scope cannot yet be estimated responsibly.

Its purpose may be to establish:

• Requirements
• Technical feasibility
• Data quality
• Risks
• Solution options
• Implementation estimate

Discovery should have its own fixed scope and output.

Example:

Review the current systems, interview three stakeholders, test the available data export, identify material constraints, and deliver an implementation recommendation with an estimated scope range.

Do not sell discovery as though it guarantees the later implementation price before the unknowns have been examined.

Scope by Phase

Large or uncertain projects can be divided into separately approved phases.

Example:

Each phase should define:

• Scope
• Inputs
• Outputs
• Price
• Timeline
• Approval
• Decision to continue

Phasing prevents the provider from committing to distant work before the earlier evidence exists.

Estimate the Full Scope Effort

A project estimate should include more than production time.

Use:

Total project effort = production + communication + coordination + quality review + revisions + administration + handover + contingency

Example

A project is expected to require:

• Production: 32 hours
• Meetings and communication: 6 hours
• Coordination: 4 hours
• Quality review: 4 hours
• Included revisions: 5 hours
• Administration and handover: 3 hours

Base effort:

32 + 6 + 4 + 4 + 5 + 3 = 54 hours

If the project has unresolved technical uncertainty, the provider may add a 15% planning contingency:

54 × 15% = 8.1 hours

Planning estimate:

54 + 8.1 = 62.1 hours

The contingency is not hidden additional scope. It is an allowance for normal variation inside the agreed work.

A genuinely new requirement should still be assessed separately.

Use Estimation Ranges When Uncertainty Is Material

False precision can make an uncertain scope look safer than it is.

Use three estimates:

• Optimistic: work proceeds with minimal difficulty.
• Most likely: normal expected conditions.
• Pessimistic: known risks occur without changing the basic scope.

A weighted estimate can be calculated as:

Expected effort = (optimistic + 4 × most likely + pessimistic) ÷ 6

Example:

• Optimistic: 40 hours
• Most likely: 55 hours
• Pessimistic: 85 hours

(40 + 4 × 55 + 85) ÷ 6 = 57.5 hours

The range remains important even when a weighted estimate is used.

A 40-to-85-hour range reveals substantially more uncertainty than the single figure of 57.5 hours.

Create a Scope Baseline

The scope baseline is the approved version against which later work is compared.

It normally contains:

• Objective
• Included work
• Work packages
• Requirements
• Volumes
• Exclusions
• Assumptions
• Constraints
• Dependencies
• Roles
• Completion conditions

The baseline should have:

• A date
• A version number
• Approval
• Supporting attachments
• A clear controlling document

Example:

Project scope baseline v1.2, approved July 26, 2026.

Avoid managing scope across:

• Several email threads
• Meeting notes
• Chat messages
• Multiple proposal versions
• Comments in unrelated files

Bring approved decisions back into one current record.

Handling Proposed Changes

A request is not automatically approved because it appears useful.

When new work is proposed, assess its effect on:

• Objective
• Deliverables
• Work volume
• Requirements
• Cost
• Schedule
• Quality
• Dependencies
• Risk
• Other customer commitments

Possible responses include:

• Replace existing work
• Use remaining contingency
• Add time
• Add price
• Move the work to a later phase
• Create a separate project
• Decline the request

The detailed process for preventing and handling uncontrolled expansion belongs to scope-change management. At the scope-definition stage, the important task is to establish that changes will be evaluated against the approved baseline before work begins.

Project Scope Statement Template

Use the following structure.

Project: [Project name]
Purpose: [Why the project exists]
Objective: [What must be true at completion]
Included work: [Activities and responsibilities covered]
Work packages: [Major groups of work]
Volume limits: [Pages, users, records, locations, systems, or other units]
Requirements: [Functional, quality, performance, and compliance conditions]
Exclusions: [Related work not included]
Customer responsibilities: [Inputs, access, decisions, feedback, and approvals]
Assumptions: [Conditions treated as true for planning]
Constraints: [Budget, time, technology, location, or other limits]
Dependencies: [Customer, provider, and external dependencies]
Interfaces: [Handoffs among people, systems, or suppliers]
Communication: [Meetings, channels, response times, and participants]
Review points: [Approval stages and reviewers]
Completion: [Conditions defining completed work, acceptance, and closure]
Change process: [How additional or changed work is assessed]
Baseline version: [Version, date, and approver]

Project Scope Examples

Website redesign

Included:

• One homepage
• One about page
• Four service-page templates
• One contact page
• Responsive desktop and mobile design
• Development in the existing content-management system
• Migration of supplied approved copy
• Functional testing
• One training session

Excluded:

• Copywriting
• Photography
• Translation
• Ecommerce
• Custom third-party integrations
• Ongoing maintenance

Assumptions:

• Customer supplies final copy before development.
• Existing hosting supports the required system.
• One reviewer consolidates feedback.

Constraints:

• Existing brand identity remains unchanged.
• Website must launch by the stated event date.

Data migration

Included:

• Review of one sample export
• Field mapping
• Import of up to 20,000 validated records
• Duplicate detection using agreed rules
• Test import
• Final import report

Excluded:

• Manual reconstruction of missing records
• Translation
• Correction of source-system errors
• Integration development

Dependencies:

• Customer supplies a final export.
• Target system remains available.
• Customer approves the field map.

Product photography

Included:

• Five supplied products
• Four final images per product
• White-background setup
• Standard colour correction
• JPEG and TIFF delivery
• One selection round

Excluded:

• Models
• Location rental
• Styling materials
• Packaging redesign
• Animated video
• International shipping of products

Constraints:

• Products must arrive undamaged.
• Shoot is completed at the provider’s studio.
• Final delivery depends on customer selection by the review deadline.

Software configuration

Included:

• One workspace
• Five user accounts
• Three workflow stages
• Two approved automations
• Import of up to 5,000 valid contacts
• Administrator training

Excluded:

• Custom software development
• Third-party subscription charges
• Historical data cleaning
• Additional departments
• Continuing support after the stated period

Assumptions:

• Required functions are available on the customer’s current subscription.
• The customer owns the imported data.
• One administrator is available for training.

Project Scope Metrics

Unplanned-work ratio

Unplanned-work ratio = Hours spent on work outside the baseline ÷ total project hours × 100

Record why the work occurred:

• Unclear original scope
• Failed assumption
• Approved change
• Provider error
• Customer request
• External event

Scope-estimate variance

Scope-estimate variance = Actual effort − estimated effort

Calculate by work package to identify where estimation fails.

Assumption-failure rate

Assumption-failure rate = Material assumptions proven false ÷ assumptions recorded × 100

The objective is not necessarily zero. The metric shows whether assumptions are being identified and verified effectively.

Dependency-delay time

Dependency-delay time = Total time work is blocked by unmet dependencies

Separate delays controlled by:

• Customer
• Provider
• Third party

Review-cycle time

Review-cycle time = Time from submission for review to approval

A long review cycle may reveal unclear authority, too many reviewers, or insufficient acceptance criteria.

Scope-completion rate

Scope-completion rate = Approved work packages completed ÷ approved work packages due × 100

Do not use this metric alone.

A project can complete every work package and still fail to produce a useful outcome.

Common Project-Scope Mistakes

Defining only the deliverables

The outputs are named, but assumptions, dependencies, responsibilities, and exclusions remain unwritten.

Using vague quantities

Terms such as small, basic, complete, reasonable, and standard are left undefined.

Ignoring coordination

The estimate covers production but excludes meetings, stakeholder management, testing, and handovers.

Treating assumptions as facts

The provider prices the work before verifying data quality, technical compatibility, or customer readiness.

Forgetting interfaces

Each individual task appears simple, but the handoffs between systems or providers create substantial complexity.

Fixing every project variable

The customer expects a fixed result, deadline, price, and quality despite unresolved uncertainty.

Using exclusions that are too general

“Anything not listed is excluded” replaces a useful explanation of the most likely misunderstandings.

Allowing several decision-makers

Multiple stakeholders can alter the work, but no one owns final approval.

Failing to version the scope

Different parties work from different proposal, email, and specification versions.

Treating customer delays as invisible

The delivery promise assumes immediate access, feedback, and approval.

Confusing project completion with business results

The provider accepts responsibility for wider outcomes controlled by customer implementation or market conditions.

Starting before critical unknowns are resolved

A fixed implementation price is agreed before the data, system, or requirements have been inspected.

Project Scope Checklist

Purpose and objective

• The business reason for the project is clear.
• The objective describes an observable completed state.
• The scope supports the intended customer value.

Included work

• Major work packages are identified.
• Supporting work such as communication and quality review is included.
• Volume units can be measured.
• Requirements are recorded.

Boundaries

• Relevant exclusions are explicit.
• Communication and meeting limits are defined.
• Review and revision boundaries are clear.
• Unsupported environments or requests are identified.

Planning conditions

• Assumptions are documented.
• Important assumptions have verification dates.
• Constraints are visible.
• Customer, provider, and external dependencies are mapped.
• System and supplier interfaces are understood.

Responsibility

• Each critical input has an owner.
• One reviewer consolidates feedback.
• Approval authority is identified.
• Customer delays have stated consequences.

Estimation

• Production and non-production effort are included.
• Uncertainty is shown through a reserve or range.
• Capacity exists to deliver the complete scope.
• The estimate is tied to the documented assumptions.

Baseline and completion

• Completion conditions are explicit.
• Handover and closure are included.
• The scope has a version and approval date.
• Proposed changes will be compared with the baseline.

Frequently Asked Questions

What is project scope?

Project scope is the complete boundary of work required to produce an agreed result under defined assumptions, constraints, dependencies, responsibilities, and completion conditions.

What should a project scope include?

It should include the purpose, objective, included work, volume, requirements, exclusions, assumptions, constraints, dependencies, interfaces, roles, review points, completion rules, and change process.

What is the difference between project scope and deliverables?

Deliverables are the outputs supplied. Scope defines the work, limits, conditions, and responsibilities surrounding those outputs.

What is an in-scope item?

An in-scope item is work or responsibility explicitly included in the approved project baseline.

What does out of scope mean?

Out of scope means the work is not included in the current project obligation. It may be declined, exchanged for another item, added through an approved change, or handled as separate work.

Why should exclusions be written?

Exclusions address related work a customer might reasonably assume is included. They reduce reliance on different interpretations of the same project description.

What is a scope assumption?

A scope assumption is a condition treated as true when planning the project, such as the availability of valid data or one authorized reviewer.

What happens when an assumption is false?

The parties should assess its effect on the work, price, schedule, risk, and feasibility. A false assumption may require a correction, approved change, new phase, or project cancellation.

What is a project constraint?

A constraint is a fixed limit such as budget, deadline, technology, location, regulation, or available capacity.

What is a scope baseline?

A scope baseline is the approved, versioned description of the project boundary used to evaluate progress and proposed changes.

Can project scope remain flexible?

Yes. A project can fix capacity, time, or objective while allowing selected work to remain flexible. The flexible elements and decision rules must still be defined.

When should discovery be a separate project?

Use a separate discovery project when technical feasibility, requirements, data quality, risk, or implementation effort cannot yet be estimated responsibly.

How detailed should project scope be?

Use enough detail for both parties to identify the obligation, estimate it, assign responsibilities, verify completion, and recognize a proposed change. More complex, expensive, or risky projects require more detail.

Who should approve project scope?

The customer representative with authority to commit budget, accept the project boundaries, and coordinate affected stakeholders should approve it together with the provider.

Key Takeaways

• Project scope defines the complete project boundary, not only its deliverables.
• State the purpose and completed objective before listing activities.
• Use measurable units for volume, complexity, access, and duration.
• Divide the project into work packages to reveal hidden work.
• Record assumptions, constraints, dependencies, and interfaces explicitly.
• Include communication, coordination, quality review, and handover in the estimate.
• Use fixed, flexible, timeboxed, or phased scope according to the level of uncertainty.
• Separate work completion from customer acceptance and later benefit realization.
• Create one approved, versioned scope baseline.
• Evaluate proposed additions against that baseline before performing them.