Analyze the scope impact of a change request

Author: AILesson8 min setupTested with:ChatGPTReviewed: 2026-08-28

Quick answer

Trace a proposed change through deliverables, schedule, cost, quality, operations, and commitments. Provide: Approved project baseline, Change request, Current status and decision rules. Expected result: A decision-ready impact assessment with options, evidence gaps, and approval conditions.

Add your context

Your text stays in this browser. AILesson Prompts does not send it to a model or server.

Approved project baselineChange requestCurrent status and decision rules

Your prompt

Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt

Prepare a change-impact assessment without treating the request as approved.

Approved baseline:
[baseline]

Requested change, rationale, evidence, and timing:
[request]

Current state, constraints, estimates, authority, and trade-offs:
[context]

First restate the requested delta against the baseline and flag ambiguity. Trace direct and second-order impact across objectives, users, requirements, deliverables, data, interfaces, dependencies, staffing, schedule, budget, quality, security/privacy, accessibility, contracts, training, support, operations, analytics, documentation, and prior commitments only where relevant. Separate known facts, estimates, assumptions, and unresolved questions. Identify completed work that may be retained, reworked, or discarded. Do not invent cost or dates.

Offer at least three genuinely different choices when evidence permits: accept now, stage or narrow, and defer or reject; include doing nothing. For each, show benefits, harms, effort range, schedule range, reversibility, risks, validation needed, and what must leave scope if time/capacity is fixed. Name the decision owner, consulted parties, deadline, and approval evidence; if absent, mark Unassigned. End with a recommendation conditional on stated priorities, not an unsupported verdict, plus a post-decision baseline-update checklist.

Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.

From input to outcome

A worked example

See how concrete context turns this recipe into a usable result

Actual input

Approved project baseline: Approved: launch an English self-service help center on 30 September 2026 with 40 migrated articles, search, feedback buttons, accessibility review, analytics, and agent training. Out of scope: localization and authenticated account content. Budget has no contingency. Support director owns scope; security approves authenticated experiences.
Change request: On 28 August, regional lead asks to add Spanish for the 40 articles at launch because 22% of July tickets came from Spanish-language browser settings. The 22% is a browser-setting proxy, not a recorded language preference. Request also says customers should see order-specific help, but does not define which account data. Desired date remains 30 September.
Current status and decision rules: Ten English articles are approved; 30 are in editing. Search template and analytics are built. Vendor estimates translation at 8-12 working days after final English copy, excluding review. No bilingual reviewer is assigned. The platform can host locale paths. Authentication/security discovery has not started. Team has one writer and one developer fully allocated. Date may move only with COO approval.

Example output

Delta: Spanish localization of 40 public articles is one change; order-specific authenticated help is a second, undefined change and should not be bundled. Both are outside the approved baseline. The 22% browser-setting figure supports investigating demand but does not establish preferred language or benefit size.

Known impacts for localization: 30 source articles are not final; translation cannot complete until final copy; vendor estimate is 8-12 working days plus an unknown review duration; no reviewer or contingency budget exists. Locale paths are technically supported. Search indexing, analytics segmentation, accessibility review, agent training, feedback handling, content ownership, and post-launch updates all gain a Spanish variant. Ten approved articles may be retained as English source; translated output remains new work. Cost and launch-date effect cannot be finalized without quote, source-freeze date, reviewer capacity, and localization acceptance criteria.

Options: A—accept all 40 for 30 Sep only if a quote, qualified reviewer, source freeze, and end-to-end search/accessibility test demonstrate feasibility; high schedule risk and authenticated help remains excluded. B—stage a validated subset of highest-evidence public articles, label coverage accurately, and schedule the remainder after launch; lower initial breadth, reversible, requires demand sampling and director approval. C—keep English baseline and run a two-week language-preference/content-demand study, then decide localization; protects date but delays Spanish access. D—add authenticated order help now: not estimable and not recommended before data fields, user need, threat model, and security owner are defined.

Conditional recommendation: if 30 Sep is fixed, choose B only after demand and reviewer validation; otherwise C. Support director decides scope by 4 Sep; COO is consulted only for date movement; security separately gates any authenticated discovery. After decision, update scope statement, budget, schedule/dependencies, acceptance and accessibility criteria, analytics taxonomy, training/support, risk log, and change log.

Why this works

1
Comparing the request with an explicit baseline prevents invisible scope expansion
2
Options expose the trade-off among time, capacity, and scope instead of hiding it in a single estimate

Check the result

Is the requested delta stated against the approved baseline rather than described in isolation
Are facts, estimates, assumptions, and unanswered questions kept separate
Does each option show what changes in scope, time, cost, risk, and approval

Use it with confidence

Frequently asked questions

Practical answers about when to use this recipe, what to provide, and where human review still matters

What should I prepare before using “Analyze the scope impact of a change request”?

For “Analyze the scope impact of a change request,” prepare Approved project baseline, Change request, and Current status and decision rules. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Analyze the scope impact of a change request” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A decision-ready impact assessment with options, evidence gaps, and approval conditions—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Analyze the scope impact of a change request”?

The published test record for “Analyze the scope impact of a change request” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.

More ways to explore