Enterprise AI Project Wiki · Scope and change
Change request
Also calledChange request · CR · Request for change · Modification request
A change request is a formal record proposing a modification to an identified document, deliverable, or baseline. It connects the current state and proposed state with the reason, impact, options, decision authority, implementation, and verification requirements, so that a team can determine whether a change is necessary, worthwhile, and safe before it alters a commitment or controlled system, and can update all affected baselines after the decision.
A change request is a proposal, not an approval
New information appears after delivery starts: priorities move, assumptions fail, users identify another need, risks become issues, or testing shows that the original design must change. A change request puts these developments through one visible and reviewable route instead of allowing a meeting, chat message, or code commit to alter the project silently.
Submitting the request establishes that a modification has been formally proposed. It does not commit budget, date, or implementation. Reviewers may ask for more evidence, while the decision authority may approve, approve with conditions, defer, reject, or accept withdrawal. Until the applicable approval exists, the proposed state is not the new baseline.
Change control does not exist to freeze an imperfect plan. It protects the quality of decisions and the consistency of commitments. A sound process allows necessary change while showing what it replaces, what it displaces, what risks it introduces, and what happens if it is not approved.
When a formal change request is required
The main test is not whether the work looks large. It is whether the proposal changes an object already agreed and controlled. The organisation should define in advance which baselines, financial thresholds, risk levels, and system changes enter its change process.
Scope or delivery outcome changes
A user group, business scenario, feature, interface, dataset, environment, document, training activity, operating responsibility, or explicit exclusion is added, removed, or replaced.
Completion conditions or quality gates change
Acceptance criteria, test samples, performance targets, security requirements, release gates, tolerances, or mandatory stop conditions are modified.
Plan or resource baselines change
A committed milestone, delivery sequence, budget, team allocation, external purchase, recurring cost, or agreed customer input is changed.
A controlled technical configuration changes
An approved architecture, interface contract, database structure, production setting, access permission, network path, supplier service, or recovery strategy is modified.
Risk treatment requires a baseline change
A risk or issue cannot be resolved inside the current boundary and requires another control, acceptance of different residual risk, suspension of a function, or a new operating method.
Approved content is cancelled or rescheduled
Stopping baseline work, moving it to a later phase, or exchanging it for another item should make the replacement of the original commitment explicit.
What an assessable change request must contain
- Can the request be identified unambiguously?
Assign an ID and record the requester, submission date, business owner, urgency, and required decision date.
Record: request ID, owner, state, and timestamps.
- Is the current baseline explicit?
Reference the effective scope, requirement, design, plan, budget, configuration, or version instead of saying only that the previous solution should change.
Record: object name, version, location, and linked items.
- Can the proposed state be verified?
Describe exactly what is added, removed, replaced, or stopped and the observable outcome; attach a rule, interface difference, or prototype where needed.
Record: target state, inclusions, exclusions, and completion conditions.
- Are the reason and consequence of no change complete?
Explain the trigger, business value, compliance or risk need, and the cost, delay, exposure, or opportunity loss of retaining the current state.
Record: supporting basis, urgency, and consequence of inaction.
- Is the affected area traceable?
Identify users, processes, deliverables, requirements, systems, data, suppliers, environments, tests, documents, and operating teams that may be affected.
Record: linked objects, dependencies, and initial impact list.
- Is there an initial implementation and verification approach?
State at least how the change may be made, whether migration or downtime is likely, how it will be tested and recovered, and who will confirm completion.
Record: implementation options, verification method, recovery direction, and owners.
Impact assessment is more than estimating development time
Assessment should compare approval, non-approval, and viable alternatives. A small code edit can cross data, security, contractual, or operating boundaries. A large proposal may still be reduced, exchanged, or introduced in stages instead of receiving a simple yes or no.
Business value and objectives
Identify the objective or problem, beneficiaries, evidence of value, and whether the proposal displaces work with a higher priority.
Scope, schedule, cost, and resources
Include analysis, design, development, data, testing, deployment, training, handover, and continuing operation, then show the effect on milestones, budget, people, and procurement.
Solution and dependencies
Examine architecture, interfaces, data models, migration, configuration, infrastructure, suppliers, and connected deliverables, preserving traceability across affected elements.
Quality, acceptance, and completed evidence
Determine which criteria, cases, and passed results must change or run again. State explicitly whether earlier evidence still applies to the proposed state.
Security, privacy, compliance, and commercial terms
Assess permissions, data purpose and movement, threat surface, record retention, regulatory duties, licences, purchasing, and any change in price or responsibility.
Release, operation, and recovery
Address downtime, capacity, monitoring, support, alerting, backup, rollback, continuity, and long-term maintenance, not merely whether deployment is technically possible.
Non-approval and alternatives
Present the outcome of retaining the baseline alongside a smaller scope, priority exchange, deferral, pilot, or different technical approach.
The end-to-end path from submission to closure
Register and link the request
Assign an ID, retain the original proposal, and connect the requirement, defect, risk, issue, decision, or customer communication that triggered it.
Triage and check completeness
Determine whether it changes a controlled baseline, duplicates another request, or needs the emergency route, and return missing information for completion. Triage is not approval.
Run a cross-functional impact assessment
Involve business, delivery, engineering, data, security, testing, operations, finance, procurement, and suppliers in proportion to actual impact, producing estimates, risks, and options.
Submit to the proper decision authority
Use delegated levels for money, scope, time, risk, and contractual commitment: this may be a project or product owner, change control board, customer, or another named role.
Record and communicate the decision
Save the decision maker, date, state, rationale, conditions, effective boundary, and follow-up ownership, then notify every affected party rather than relying on a verbal agreement.
Update baselines after approval
Before implementation, or as authorised, synchronise scope, requirements, design, budget, plan, configuration, acceptance material, contract schedules, and version records while retaining the old state.
Implement through a controlled plan
Turn the approved content into executable work using the named versions, environments, permissions, and deployment route. A newly discovered material impact returns for assessment instead of silently extending approval.
Verify, hand over, and close
Verify against approved conditions, update operating and handover material, confirm that linked records are consistent and temporary measures removed, and have the agreed role close the request.
States, decision authority, and emergency change
| State or decision | What it means precisely |
|---|---|
| Submitted / information required | The request has been registered, or lacks evidence needed for assessment. Neither state authorises implementation. |
| Under assessment | Relevant roles are analysing impact and options. It signals no approval preference and is not authority to start the change early. |
| Approved | The proper authority permits implementation within the recorded scope, conditions, budget, and timing. A material departure requires a new decision. |
| Conditionally approved | Authority applies only after defined prerequisites, limits, tests, reviews, or deadlines are met. Each condition must be verifiable. |
| Deferred / rejected | Deferral retains the request but postpones decision or implementation; rejection retains the current baseline. Record rationale and reconsideration conditions. |
| Implemented / closed | Implemented means the modification was made. Closure follows only after verification, baseline and record updates, and transfer of responsibility. |
Enterprise AI change requests must identify the full behaviour baseline
Model and service changes
Record provider, model ID, fixed version or moving alias, region, parameters, and deprecation timing. A managed model update can alter quality, latency, cost, and safety even when application code stays unchanged.
Prompts, guardrails, and human rules
System prompts, output schemas, content filtering, refusal, human approval, and escalation rules all shape behaviour. Assess both excessive blocking and controls that cease to work.
Knowledge and retrieval chain
A new source, permission, cleaning method, chunking, embedding, index, retrieval, or reranking setting changes the basis of answers. Specify data authority, expiry and deletion, rebuild scope, and the recoverable knowledge state.
Tools, actions, and permissions
Adding write-back, messaging, ordering, ticketing, or approval creates new real-world effects. Assess least privilege, parameter confirmation, idempotency, limits, audit, failure compensation, and human takeover.
Evaluation baseline and revalidation
Identify affected normal, exceptional, insufficient-information, adversarial, sensitive-data, and high-impact action samples. Record evaluation-set and rubric versions; do not inherit acceptance from an old average score.
Third-party change and continuing monitoring
Provider models, APIs, and policies can change outside the project. Include notification terms, version pinning, drift monitoring, reassessment triggers, and fallback options in the impact and operating plan.
Stop, recovery, and incident linkage
Define stop conditions such as unauthorised disclosure, irreversible action, unsupported critical facts, bypassed human approval, or missing audit, and name recoverable application, model, prompt, knowledge-index, and tool-configuration targets.
Evidence required before closing the request
- The decision record is complete
Retain who approved, conditionally approved, deferred, rejected, withdrew, or superseded it, with delegated authority, date, rationale, and applicable boundary.
- Old and new baselines can be compared
Scope, requirements, design, plan, budget, configuration, and commercial material are updated while prior versions, differences, and effective dates remain traceable.
- The implemented object is identifiable
Record the actual artifacts, configuration, database migrations, models, prompts, knowledge indexes, tool permissions, and deployment environment instead of only saying complete.
- Verification is reviewable
Bind affected criteria, tests, retests, regression, security checks, operating observation, and exceptions to the implemented version and identify the confirmer.
- Operation and handover are synchronised
Monitoring, alerts, recovery, support, training, user guidance, asset records, and recurring costs have owners.
- Outstanding work has a destination
Residual risks, deferred content, temporary controls, observation periods, and removal dates have an owner and separate record instead of being hidden by closure.
Records commonly confused with a change request
| Related record | How it differs from a change request |
|---|---|
| Requirement | A requirement expresses a stakeholder need or constraint. A change request proposes modification of a controlled requirement or another baseline and carries the impact and decision. |
| Defect | A defect records failure to meet an existing requirement. Restoring the original criterion usually does not change scope; a different solution, cost, or commitment may require a linked request. |
| Risk | A risk is uncertainty and its effect. If treatment modifies a baseline, the request obtains authority while the risk record continues to track residual exposure. |
| Issue or incident | An issue has occurred, and incident handling prioritises containment and recovery. A normal or emergency request governs any permanent controlled-state modification. |
| Task or backlog item | A task describes work already selected for execution. A change request precedes that decision and explains whether to change and the complete consequence. |
| Decision record | A decision record preserves a choice and its rationale. The request also covers the changed object, impact assessment, authority, implementation, verification, and closure. |
| Contract change order | A contract change order has specific legal and commercial effect. A project request may trigger it but cannot replace required signatures, pricing, or allocation of responsibility. |
| Change control | Change control is the overall system for identifying, recording, evaluating, accepting or rejecting, and tracking modifications. A change request is the record carrying one proposal through it. |
Sources and scope
This entry explains the formal change request used when a proposed modification may alter a project or system baseline. It is not a spoken suggestion, ordinary task, defect, risk or issue record, and it does not mean that a change has been approved, implemented, or incorporated into a contract. Organisations may use project tools, ticketing systems, configuration-management systems, or commercial procedures with different names and forms. What matters is that a proposed change to an agreed scope, deliverable, requirement, design, plan, budget, configuration, or operating baseline identifies the object, receives an impact assessment and a decision from the proper authority, and remains traceable from submission through closure.
- PMI Lexicon of Project Management Terms: formal definitions of change request, change control, and change control board
- UK Government GovS 002 section 7.7: recording, impact assessment, authorisation, communication, baseline update, and closure
- NASA Software Engineering Handbook SWE-082: assess and authorise configuration changes before implementation and define an end-to-end request process
- NASA Systems Engineering Handbook: formal change channels and assessment of system impact, non-approval consequences, and technical and fiscal margins
- NIST AI 600-1: version records, change management, reassessment, monitoring, incident response, and third-party change for generative AI