Start here

1. Copy the prompt text provided in the appendix.
2. Paste it into an ordinary AI chat interface that accepts text input.
3. Replace [PASTE HERE] with your Original Scope Statement and Change Request Text.
4. Check the output: Ensure it is a Markdown table listing only "Addition" or "Modification" types, with no cost or time estimates.

Introduction

This reusable prompt helps office professionals manage scope creep by objectively analyzing change requests. It strictly separates new requirements from the original agreement, preventing implicit acceptance of extra work. The tool focuses solely on identifying what has changed, leaving impact assessment to human reviewers.

Prerequisites

• Access to a standard AI chat interface.
• Two distinct text inputs: the agreed-upon project scope and the new request (email, memo, or transcript).

Permissions and Limitations

• No Runtime Execution: This is a text-based prompt template. Source reviewed; runtime not tested.
• No Estimation: The prompt is constrained to avoid generating cost, timeline, or resource estimates.
• Privacy: Do not paste sensitive personal data or confidential trade secrets into public AI interfaces.

FAQ

Q: What if the change request is vague? A: The prompt is designed to flag vague requests. If details are missing, it will note that clarification is needed rather than guessing.

Q: Can this handle technical implementation details? A: No. Stick to functional requirements. The prompt avoids inferring technical solutions to keep the focus on business scope.

Attribution

Source: TokRepo Original Prompt (CC BY 4.0). Reference: ChatGPT release notes.

Complete reusable prompt

Role: Project Scope Change Analyst

Objective

Analyze a provided Project Scope Change Request (email, transcript, or memo) and compare it against the Original Project Scope Statement. Your goal is to extract only the changes and present them in a structured "New Requirements vs. Original Scope" table.

Critical Constraint: Do NOT estimate effort, cost, timeline impact, or resource needs. Your role is strictly to identify what has changed, not how much it will take. Leave all impact-related fields blank for human estimation.

Input Data

You will receive two distinct inputs:

1. Original Scope Statement: A text block defining what was originally agreed upon (features, deliverables, exclusions).
2. Change Request Text: A raw communication (email, meeting notes, ticket description) proposing changes, additions, or modifications.

Step-by-Step Instructions

1. Parse the Original Scope

Identify the baseline deliverables and explicit exclusions mentioned in the Original Scope Statement. Create a mental list of these items.

2. Analyze the Change Request

Read the Change Request Text carefully. Identify specific statements that:

• Add new features or deliverables not in the original scope.
• Modify existing features significantly (e.g., changing "basic reporting" to "real-time analytics").
• Explicitly remove items previously considered in-scope (if stated).

3. Classify Changes

For each identified change, determine its relationship to the original scope:

• Addition: New functionality not previously requested.
• Modification: Significant alteration to an existing feature's definition.
• Clarification: Minor wording change that does not alter functional requirements (exclude these from the final table unless they reveal a hidden assumption).

4. Construct the Table

Create a Markdown table with the following columns:

• Change ID: Sequential number (1, 2, 3...).
• Type: "Addition" or "Modification".
• Description of Change: Concise summary of the new requirement derived from the request text.
• Reference to Original Scope: Quote or summarize the relevant part of the Original Scope that this change contradicts, adds to, or modifies. If there is no direct reference (pure addition), write "N/A - New Item".
• Notes/Context: Any specific constraints or reasons mentioned in the request (e.g., "Client stated this is urgent due to regulatory change"). Do NOT add your own interpretation.

5. Handle Uncertainty & Missing Inputs

• If the Original Scope Statement is missing or empty, state: "ERROR: Original Scope Statement not provided. Cannot perform comparison. Please provide the baseline scope."
• If the Change Request Text is vague (e.g., "Make it better"), do not guess. Write in the table: "Vague Request: Specific details missing. Requires clarification from requester."
• If a change implies a technical solution but the scope is functional, stick to the functional requirement. Do not infer technical implementation details.

6. Final Review Check

Before outputting, verify:

• No effort/cost estimates are included.
• Every row in the table represents a tangible change in requirements.
• The tone is neutral and objective.
• Direct quotes from the source texts are used where appropriate to maintain accuracy.

Output Format

Provide the result in the following structure:

Scope Change Analysis Report

Summary: [One sentence summarizing the net impact, e.g., "The request introduces 3 new modules and modifies 1 existing feature."]

Detailed Changes Table: [Insert Markdown Table Here]

Missing Information / Clarifications Needed: [List any ambiguities in the Change Request that prevent clear classification, or leave blank if none.]

Fictional Mini Example

Input 1: Original Scope Statement "The project includes a user login page with email/password authentication. It excludes social media login options. The dashboard will display static monthly reports."

Input 2: Change Request Text "Hi team, we need to add Google and Facebook login buttons to the sign-in page because users are complaining. Also, the boss wants the dashboard to update every hour instead of once a month. We can drop the PDF export feature to save time."

Expected Output Shape:

Scope Change Analysis Report

Summary: The request adds social authentication, increases data refresh frequency, and removes a delivery format.

Detailed Changes Table:

Missing Information / Clarifications Needed:

• Specific API providers for social login beyond Google/Facebook?
• Technical feasibility of hourly updates not assessed in this step.

Pass/Fail Checks for This Example

1. Pass: The table correctly identifies "Social Login" as an Addition contradicting the exclusion.
2. Pass: The table correctly identifies "Hourly Updates" as a Modification of the "Static Monthly" scope.
3. Pass: The table correctly identifies "PDF Export" removal (even if not explicitly in the short original snippet, it's treated as a scope reduction/change).
4. Fail: If the output includes estimates like "This will take 2 weeks" or "Cost increase $500".
5. Fail: If the output interprets "boss wants" as a technical constraint rather than a business requirement.

User Instructions

Paste your Original Scope Statement and Change Request Text below to generate the analysis.

Original Scope Statement: [PASTE HERE]

Change Request Text: [PASTE HERE]

References and reuse

• ChatGPT release notes

Original TokRepo prompt · CC BY 4.0. Reference documents retain their own rights.