Enterprise AI Project Wiki · Scope and change
Phase-one scope
Also calledPhase 1 scope · Phase-one scope · Initial-phase scope · First delivery phase
Phase-one scope is the authorised set of objectives, users and business scenarios, deliverable results, necessary work, technical and data boundaries, responsibilities, cost, and completion conditions to be delivered in the first agreed stage of a wider project. It also identifies what is excluded, deferred, or dependent on outside work. As its own baseline, it can be estimated, scheduled, delivered, and accepted separately, and can support a decision to proceed, adjust, repeat, or stop at the phase gate.
Phase-one scope defines a stage before it reduces a feature list
Phase one has practical meaning only when the project defines its starting and ending states. One project may begin the phase after initial funding and end with a feasibility decision. Another may start from approved requirements and end when a limited group uses a production service. Their deliverables, work, risk, and estimating basis differ even if both are called phase one.
Phase-one scope is a subset of whole-project scope, but not an arbitrary slice of features. It covers both the intended result and the data, interfaces, environments, testing, training, handover, and management work necessary to obtain it. A visually small feature set can remain undeliverable when essential responsibility is left outside the phase.
The end of a first phase does not always mean production launch. Discovery may finish with a proceed-or-stop recommendation, alpha with evidence that an approach is viable, and beta or an initial launch with substantially different operating and risk conditions. Name, objective, and completion decision must agree.
Give phase one identifiable entry and exit gates
“Phase one” easily becomes a label that keeps moving: features accumulate, dates slip, and nobody can say when the stage is finished. Explicit entry conditions and an exit gate separate this stage from the long-term roadmap and make it possible to price, accept, and review on its own.
Phase name and version
Record the formal name, scope-document version, and applicable project. Do not let phase one, initial stage, and MVP stage refer to different content across documents.
Entry decision
State who authorised the phase, on what date and evidence, and whether funding, team, data, system access, and customer inputs are available.
Phase objective
Identify the decision to be tested, capability to be established, or working result to be delivered. 'Do a smaller part first' is not an objective that can guide trade-offs.
Time and resource boundary
Record expected start and end, critical windows, budget or effort limit, key roles, and external resources. A timebox constrains the promise but does not replace scope.
Exit conditions
List quality, evidence, handover, and open-item conditions for ending the phase, including outcomes that prevent a pass.
Gate decision
Name who decides to proceed, proceed with conditions, revise and repeat, or stop, and which material that person must review.
What executable phase-one scope contains
Phase-one boundaries rarely live in one document. Scope, pricing, plans, requirements, and acceptance each carry part of the answer. They must still point to one effective version so every participant can reconstruct the same stage, rather than sales, delivery, and the customer each holding a different “phase one.”
Target users and use boundary
Identify the roles, teams, organizations, regions, or restricted cohorts included and excluded, and whether the result is for live use, controlled trial, internal validation, or decision support only.
Included business scenarios
Name the task, trigger, end state, normal path, material exceptions, and human responsibility covered. Scenarios should serve this phase's objective rather than absorb the entire long-term backlog.
Phase deliverables
State the form, quantity, audience, and completion state of software, interfaces, configuration, data work, migration, environments, documents, training, test evidence, and phase reports.
Necessary work
Include analysis, design, development, integration, data preparation, testing, deployment, review, launch support, and handover necessary for the result. Non-interface work is not an automatic free extra.
System, data, and third-party boundary
Define systems, fields, historical periods, accounts, interfaces, and external services; who supplies and authorises each; who pays usage; and how an unavailable dependency changes the phase.
Quality and acceptance boundary
Connect each result to a version, environment, sample, criterion, evidence, and confirmer. Keep phase completion, formal business acceptance, and production authorisation distinct.
Responsibilities and inputs
Assign supplier, customer, and third-party duties for information, interfaces, review, testing, training, procurement, and operation, with due dates and delay handling.
Exclusions and connection to later work
Name items a reasonable reader might expect, state the intended later stage, and note whether the current design must preserve an interface. Deferred items still require future assessment.
Assumptions, constraints, and dependencies
Record the data quality, access timing, user volume, approval, regulatory, technical, and purchasing premises supporting the estimate, with verification points for critical uncertainty.
How to decide what belongs in phase one
Phase one is not the easiest set of features to build or the first few lines cut from a long roadmap. A stronger choice starts with a worthwhile business journey that can run end to end and leave evidence, then separates what must exist now from what can be postponed safely.
Identify the next decision the phase must support
Decide whether the gate is about further investment, solution selection, restricted availability, or production launch. Each decision requires different deliverables and evidence.
Choose users and scenarios that prove the objective
Limit roles, tasks, regions, channels, and data while retaining representative scenarios that expose core value, key dependencies, and principal risks.
Work backward from the completed result
Derive data, interfaces, permissions, exceptions, testing, environment, support, and records from the intended end state instead of retaining visible features while deleting their conditions.
Turn deferral into an explicit boundary
For later features, groups, data, automation, and operations, state why they are out, where they may belong, and whether they constrain current design. 'Improve later' is not a boundary.
Test feasibility against dependencies and risk
Confirm information, interfaces, purchasing, approvals, and people can be available within the window. An uncontrollable critical dependency changes scope, timing, or the phase objective.
Check the promise with a complete estimate
Include non-development work, customer effort, third-party and recurring cost, and uncertainty before deciding whether budget, schedule, and team support the result.
Approve one baseline across roles
Involve business, users, engineering, data, security, operations, procurement, acceptance, and delivery in proportion to risk, and approve the same scope, exclusions, and gate decision.
Can the phase-one scope support a quote and start decision?
A smaller phase is not automatically easier to price. The tighter the boundary, the more clearly it must show the work that remains essential, especially data, integration, deployment, acceptance, and customer inputs. These checks distinguish a complete stage from a low opening price that adds necessary work later.
- Does the phase have one purpose?
A single sentence identifies its result or decision and distinguishes it from the long-term vision.
Review: phase objective, business reason, and gate decision.
- Are entry and exit states identifiable?
Required authorisation and inputs at the start, and deliverables and evidence at the end, are more precise than a date range.
Review: entry criteria, exit criteria, and authorised roles.
- Does scope cover complete responsibility?
Every included scenario has an owner from trigger through result, exception, human action, and record; no critical step is hidden as customer cooperation or later work.
Review: scenario map, responsibility matrix, and deliverable list.
- Are exclusions concrete?
Users, data, systems, channels, automation, and operating services outside the phase are explicit enough to prevent a reasonable assumption of inclusion.
Review: exclusions and mapping to later stages.
- Do dependencies have an owner and date?
Information, interfaces, accounts, approvals, procurement, and testers have providers, latest dates, and a response if unmet.
Review: dependency log, owner, due date, and alternative.
- Does the quote cover all phase work?
Cost maps to results and necessary work, separates one-time, recurring, and third-party cost, and states estimate uncertainty.
Review: quote detail, pricing assumptions, resource and usage boundaries.
- Are acceptance and the next investment decision separate?
The phase can pass its own criteria without automatically authorising the next stage.
Review: acceptance plan, phase report, and gate authority.
Concepts commonly confused with phase-one scope
An MVP, pilot, proof of concept, prototype, or sprint may all occur early, but none automatically defines a contractual or delivery phase. First state the formal result this stage must produce, then choose the validation or development method that fits it; a popular label should not hide the boundary.
| Related concept | How it differs from phase-one scope |
|---|---|
| Whole-project scope | Whole-project scope covers all currently approved work and results. Phase-one scope covers the first agreed stage and states how it connects to the remaining boundary. |
| Minimum viable product (MVP) | An MVP commonly means the smallest product state that can be launched safely to gain early real feedback. Phase one may deliver an MVP, or may end with discovery, prototype, PoC, or non-public foundation work. |
| Proof of concept (PoC) | A PoC tests whether a technology or approach is feasible and may lack a complete user path and operating conditions. Phase-one scope still defines all work, responsibility, cost, and the closing decision. |
| Prototype | A prototype explores, demonstrates, or tests a design and may use non-production code and data. Phase one may deliver a prototype and decision report or require a production-capable system. |
| Pilot | A pilot lets a restricted population use a solution under defined conditions. It is a mode of use and evaluation; phase-one scope also covers build, data, support, risk, cost, and exit arrangements. |
| Sprint or iteration | A sprint is a short team planning cycle. One phase normally contains several iterations, and sprint completion does not automatically mean phase delivery, acceptance, or gate approval. |
| Product roadmap | A roadmap communicates the direction, stages, and priorities through which a product may create value. Phase-one scope is the authorised near-term baseline with delivery accountability. |
| First payment instalment | A payment milestone is a commercial settlement arrangement. Its sequence does not define phase users, scenarios, deliverables, or completion conditions. |
Enterprise AI can narrow phase-one use, but not its matching risk floor
An AI first phase can serve one role, one source set, or one output purpose. A small audience does not make risk controls optional. Once the system touches real data, produces conclusions people will use, or can call external tools, the matching permissions, refusal, human handoff, and audit controls need to exist in the same phase.
First limit who uses it and for what
The same AI capability carries very different consequences when it drafts an internal note versus changing a customer order. Phase one names the task, users, affected parties, and use of results, then states whether the system only drafts, advises, and retrieves citations or is already allowed to write data and act in external systems.
Limit knowledge and data state
List sources, fields, historical period, permissions, quality, update, and deletion owners. Sample data can support validation, but production use cannot defer authority and lifecycle indefinitely.
Identify the system combination
Trace application, model or managed deployment, prompts, guardrails, knowledge index, retrieval settings, tool permissions, and evaluation set instead of defining scope as integration with a model name.
Retain risk-based testing and human oversight
Even with few users, test normal, insufficient-information, exceptional, sensitive-data, unauthorised, and high-impact actions in proportion to use, with review, refusal, handoff, and stop rules.
Include third-party change
Provider models, APIs, policy, and price may change. State pinned versions where possible, notification, region, usage limits, reassessment triggers, and fallback arrangements.
Separate validation from real operation
A prototype or PoC must prevent real order, message, approval, and production-data effects. Real users require identity, access, monitoring, logs, incident response, recovery, and operating ownership.
Define post-phase disposition
Decide how conversations, evaluations, feedback, temporary accounts, indexes, and supplier resources are retained, migrated, or deleted, and who owns them if the project proceeds, expands, or stops.
Changing phase one and deciding at its gate
The point of phase one is not merely to produce something quickly. It is to reach an agreed gate where real results support the next decision. The stage may change during delivery, but those changes cannot quietly expand it, and prior effort alone cannot justify automatic expansion at the end.
Baseline the phase
Approve the effective scope, plan, quote, dependencies, acceptance, and exclusions so that phase one is distinct from the future vision, roadmap, and backlog.
Update forecasts from evidence
Track actual progress, cost, dependencies, and risk. Near-term planning can be more detailed than distant work, but uncertainty must remain visible rather than becoming assumed scope.
Use a change request for baseline modification
A user, scenario, dataset, interface, deliverable, date, cost, or completion-condition change is assessed against the objective, completed work, risk, and later stages, then decided by the proper authority.
Prepare phase-end material
Summarise delivered versions, acceptance, cost and progress, open issues, residual risk, operating state, lessons, recommendations, and the destination of unfulfilled requirements.
Make two separate decisions
First decide whether the phase met its own criteria. Then decide whether and how to invest in the next stage. Acceptance of phase one does not automatically approve another commitment.
Update future scope without rewriting history
Use learning to change the next phase and roadmap while preserving the phase-one baseline, changes, and decisions. A later priority cannot turn excluded work into a historical shortfall.
Sources and scope
This entry explains the staged delivery boundary commonly called phase-one scope. The expression is not a universal standard term and does not automatically mean an MVP, pilot, prototype, proof of concept, the first agile sprint, a feature-reduced full scope, or the first contract payment. Phase one may be discovery, a prototype decision, a restricted-user trial, an initial production launch, or another separately governed delivery stage. The project must identify the decision that starts it and the result and gate that end it. This entry does not take over the separate method intent of the site's article about designing an AI project's first phase as a minimum complete business journey.
- PMI Lexicon of Project Management Terms: standardized entry point for project phase, phase gate, project scope, and scope baseline
- UK Government GovS 002: stages and gates, resource authorization, progressive planning, scope and risk constraints, baselining, and controlled change
- GOV.UK Service Manual: alpha tests risky assumptions and approaches with non-production prototypes that are not publicly available
- GOV.UK Service Manual: beta covers real build, restricted-to-public users, whole journeys, support, and preparation for scale
- UK guide on assurance for agile digital services: phased risk reduction, the safe-launch boundary of an MVP, prioritised needs, and roadmap relationships
- GOV.UK Service Manual: roadmaps express long-term direction, stage objectives, priorities, and change rather than a near-term delivery baseline
- NIST AI RMF Core: intended purpose, users, targeted application scope, risk tolerance, testing, human oversight, third-party components, and proceed-or-stop decisions