Enterprise AI Project Wiki · Scope and change
Project scope
Also calledProject scope · Scope of work · Project boundary · SOW scope
Project scope is the delivery boundary stakeholders approve in an identified version: which outcomes will be delivered to which users and business scenarios in the current phase; what necessary work, systems, data, and environments are included; who owns each responsibility; how completion will be decided; and what is explicitly excluded. It is the common baseline for estimates, schedule, resources, acceptance, and change decisions.
Project scope is neither a feature list nor a sentence such as ‘build a system’
A feature list says what a system might do, but not how far the current delivery goes. ‘Support knowledge Q&A’ does not identify sources, users, permissions, citations, insufficient-information behavior, evaluation, deployment, monitoring, or human handoff, so it cannot directly support an estimate or acceptance decision.
Scope governs both results and the work needed to produce them. Listing screens, APIs, or model capabilities can omit data preparation, environments, testing, go-live, training, and handover. Listing activities alone can produce much work without a result the customer can use and accept.
Scope must have an identified version. Notes, prototypes, quotations, and requirements may evolve; only the designated baseline and its approved changes should decide whether an item belongs to the current phase.
Boundaries an executable scope must define
Document names vary, but the scope or its explicitly referenced schedules must answer the following questions.
Objective and business result
State the process being changed, target users, and intended operating state. An objective guides priority but ‘improve efficiency’ cannot replace concrete deliverables.
- Current problem and target state
- Affected teams and users
- How the result will be observed
Included business scenarios
Identify the starting event, processing path, end state, normal path, exceptions, and human intervention covered in this phase.
- Who starts the process and when
- What people and systems do
- Where the record is written and when the case closes
Deliverable results
List running software, interfaces, configuration, data work, documents, training, and handover material separately, with their form and applicable coverage.
- Software and configuration
- Data and migration results
- Operating and handover records
Systems, interfaces, and data
Name existing systems, environments, accounts, fields, and historical periods; state who provides access and whether cleansing, migration, write-back, and third-party approval are included.
- Interface direction and owner
- Data coverage, quality, and permission
- External services, licenses, and quotas
Environment, deployment, and operations
State who supplies each environment and whether domains, certificates, cloud resources, deployment, monitoring, backup, launch support, and ongoing operations are included.
- Target environment and region
- One-time delivery versus recurring service
- Production access and operating owner
Quality and completion
Point to the applicable acceptance object, criteria, samples, environment, evidence, and decision maker. ‘Customer satisfaction’ or ‘system works’ cannot be the only condition.
- Functional and business result
- Performance, security, and compatibility
- AI quality, refusal, and human handoff
Responsibilities and customer inputs
Separate supplier, customer, and shared work. Give information, interfaces, accounts, reviews, test feedback, and approvals an owner and due date.
- Delivery owner
- Business and technical approvers
- Customer and third-party dependencies
Explicit exclusions
List work a reasonable reader might assume is included but the phase will not deliver, such as historical data remediation, all-department rollout, long-term operations, or modification of a legacy system. An exclusion is a positive boundary, not a disclaimer.
Assumptions, dependencies, and constraints
Record the premises supporting the estimate and schedule and any budget, time, legal, technical, or procurement limits. A failed assumption should trigger impact analysis, not silent additional work.
How to tell whether scope is ready for estimating and scheduling
- Can every result be uniquely identified?
Each deliverable has a name, scenario, boundary, and completion state rather than catch-all phrases such as ‘related functions’ or ‘required integrations.’
Check: deliverable register, prototype, interface list, document index.
- Does the work cover complete delivery?
Data, integration, testing, deployment, acceptance, training, and handover are included or explicitly excluded, not hidden behind development.
Check: work breakdown structure, milestones, responsibility matrix.
- Are both sides of the boundary clear?
The scope states what is included and the most likely exclusions, including the boundary between this phase and later phases.
Check: scope statement, exclusions, phased roadmap.
- Does every dependency have an owner and date?
Customer material, interfaces, external accounts, procurement, and reviews are trackable inputs, not a generic duty to cooperate.
Check: dependency log, owner, latest-needed date.
- Can completion be decided from evidence?
Each result maps to acceptance criteria, a verification method, required evidence, and an authorized decision maker.
Check: acceptance criteria, test plan, approval record.
- Does pricing map back to scope?
One-time, recurring, and third-party charges correspond to scope items; unknown volumes and unconfirmed dependencies are not concealed in a fixed price.
Check: pricing schedule, charging assumptions, usage boundaries.
- Is there one effective version?
Participants know the current scope version, approver, date, and the status of prototypes, email, and meeting notes relative to it.
Check: version ID, approval, change log.
Concepts often confused with project scope
| Related concept | Difference from project scope |
|---|---|
| Product scope | Product scope describes the product's longer-term features and capabilities. Project scope describes the work for one project result; a roadmap feature is not automatically in the current phase. |
| Requirement | A requirement expresses a needed capability, behavior, or constraint. Project scope selects which requirements this phase will meet and includes the environments, tests, documents, and services needed around them. |
| Deliverable list | Deliverables are central to scope but do not alone define users, responsibilities, exclusions, dependencies, and completion conditions. |
| Work breakdown structure | A WBS decomposes the work needed to complete a project into plannable levels. It helps cover scope, while the scope also defines purpose, boundary, ownership, and acceptance. |
| Quotation | A quotation converts known scope, assumptions, and charging rules into a price. The same price does not imply the same scope; changed scope requires a new impact assessment. |
| Contract scope | A contract can combine scope, price, liability, intellectual property, remedies, and other legal terms. Project scope is the delivery-boundary concept and is not a substitute for contract interpretation. |
| First-phase scope | The first phase is a coherent subset of the larger objective with its own users, scenarios, deliverables, and acceptance loop—not an arbitrary slice of a long-term feature list. |
How to establish an executable scope baseline
Confirm the objective and decision makers
Have an accountable business representative set the objective, priorities, and unacceptable outcomes, and name technical, data, security, and acceptance approvers.
Map the complete business loop
From trigger through processing, exceptions, human intervention, records, and closure, define the roles, teams, channels, and data covered in this phase.
List results and necessary work
Work backward from the business result to software, interfaces, data, environments, tests, training, and handover; use a WBS or equivalent structure to check coverage.
Record inclusions, exclusions, assumptions, and dependencies
Resolve ambiguities that can change price or schedule and give third-party approval, customer input, and legacy constraints owners and dates.
Bind acceptance and charges
Assign completion evidence to each result, map one-time, recurring, and third-party cost, and state how volume changes will be handled.
Review across roles
Involve business, users, technology, data, security, operations, procurement, and the supplier as risk requires; identify terms that different groups interpret differently.
Approve and freeze the version
Record the scope document, referenced schedules, version, date, approvers, and open items. Only this baseline and approved changes govern execution and comparison.
How to handle scope change without silently adding work
A baseline does not prohibit change; it makes the impact and decision visible.
Register the proposed change
Record who requested what, why, by when, and which users, workflows, data, interfaces, and deliverables it may affect.
Classify the issue
Defect correction, clarification of existing scope, failed assumption, and new requirement require different treatment; do not call all of them an ‘optimization.’
Assess the full impact
Evaluate effort, price, schedule, people, architecture, security, data, acceptance, completed work, and other scope items—not development time alone.
Present options
Approve and rebaseline, swap work of comparable impact, defer, reject, or run time-boxed analysis. State the consequence of each option.
Obtain an authorized decision
Use the agreed authority for budget, time, and delivery commitments so a developer or individual user cannot change scope accidentally in conversation.
Synchronize all baselines
After approval, update scope, requirements, prototypes, price, plan, tests, and acceptance material together; notify owners and preserve the prior version and rationale.
Additional scope boundaries for enterprise AI projects
Target tasks and prohibited uses
Define the tasks, users, and use of results, and identify high-risk decisions, professional judgment, or out-of-knowledge uses the system must not complete autonomously.
Knowledge and data coverage
List repositories, document types, historical periods, fields, permissions, and update owners. ‘Use customer data’ does not define cleansing, labeling, migration, or ongoing maintenance.
Answer and action boundary
Distinguish drafting, recommending, cited retrieval, system write-back, and external action. Each added tool permission expands authorization, confirmation, audit, failure, and compensation scope.
Model and third-party boundary
Allocate model selection, integration, fine-tuning, evaluation, usage charges, region, version changes, and fallback ownership. A model name cannot define complete solution scope.
Quality and risk coverage
Set task-specific samples, grounding, correct refusal, insufficient-information behavior, sensitive-data and authorization controls, human handoff, and hard-stop conditions; document unsupported capability and residual risk.
Human oversight and operations
Name who reviews output, takes exceptions, handles feedback, and updates knowledge and evaluation sets; state whether production monitoring, re-evaluation, cost control, and incident response belong to the phase.
Combination version
AI behavior emerges from the application, model, prompt, guardrails, knowledge index, retrieval settings, and tool permissions. Scope and acceptance should identify this combination rather than deliver a prompt or model endpoint in isolation.
Sources and scope
This entry explains project scope in project management and enterprise AI delivery: the work and boundaries required to produce the agreed result in the current phase. It does not replace legal contract terms, a complete requirements specification, a long-term product roadmap, individual acceptance criteria, a pricing schedule, or a change request. Organizations may distribute scope across a charter, scope statement, statement of work, requirements baseline, work breakdown structure, and contract schedules. A project must identify which versions collectively form the effective scope and how conflicts are resolved.
- PMI Lexicon of Project Management Terms: project scope, product scope, scope management plan, and scope baseline
- ISO 21502:2020: project-management guidance across organizations, project types, and delivery approaches
- UK Government GovS 002: governance, planning and control, change, procurement, and solution delivery
- NASA Software Engineering Handbook: using a WBS to cover necessary work, dependencies, and frequently omitted activities
- US Federal Acquisition Regulation 37.6: describing required results and assessing work against measurable standards
- NIST AI RMF Core: intended purpose, users, requirements, knowledge limits, targeted application scope, human oversight, and third-party components