Project Scope Definer
The Project Scope Definer produces a structured scope document that draws a sharp boundary around what a project will and will not deliver. It forces you to articulate deliverables, exclusions, assumptions, constraints, and acceptance criteria before work begins, which is the single most effective way to prevent scope creep, misaligned expectations, and the "I thought we agreed on X" conversations that derail projects mid-stream.
Project managers, team leads, freelancers scoping client work, and product managers defining feature boundaries all use this template. It is especially critical for cross-functional projects where multiple stakeholders have different mental models of what "done" looks like. The output serves as a reference document that everyone can point to when new requests surface: either the request is in scope and was planned for, or it is out of scope and requires a change request.
The prompt produces more than a list of deliverables. It captures the assumptions that would break the plan if wrong, the dependencies that could block progress, and the acceptance criteria that define when each deliverable is truly complete. These are the elements that informal project kickoffs skip, and they are exactly the elements whose absence causes projects to run over budget and past deadline.
This prompt is just the starting point
Score it with AI, optimize it with one click, track versions, and build your prompt library.
The Prompt
Create a project scope document based on the following inputs: **Project Name**: [PROJECT NAME, e.g., "Website Redesign", "CRM Migration", "Q3 Marketing Campaign"] **Project Summary**: ``` [DESCRIBE THE PROJECT IN 2-3 SENTENCES, e.g., "Redesign our company website to improve conversion rates and update the visual brand. The current site was built 4 years ago and has a 1.2% conversion rate on the pricing page. We want to launch the new site before the September trade show."] ``` **Key Stakeholders**: ``` [LIST THE PEOPLE INVOLVED AND THEIR ROLES, e.g., - Sarah (VP Marketing): project sponsor, final approval - Dev team (3 engineers): build and deploy - Design agency (external): visual design and prototypes - Content team (2 writers): copy for all pages] ``` **Known Constraints**: - Budget: [BUDGET, e.g., "$25,000 total including agency fees"] - Timeline: [DEADLINE, e.g., "Must launch by August 30"] - Resources: [TEAM AVAILABILITY, e.g., "Dev team is 50% allocated to this, other 50% on maintenance"] - Technical: [TECHNICAL CONSTRAINTS, e.g., "Must stay on WordPress, cannot migrate CMS"] **What Success Looks Like**: [HOW YOU WILL KNOW THE PROJECT SUCCEEDED, e.g., "Pricing page conversion rate reaches 2.5% within 60 days of launch"] Generate a project scope document with these sections: ### 1. Project Objective A single paragraph stating what this project will accomplish and why it matters. This should pass the "elevator pitch" test: anyone reading it should understand the project in 30 seconds. ### 2. Deliverables A numbered list of every concrete output the project will produce. For each deliverable: - Description of the deliverable - Owner (who is responsible) - Acceptance criteria (how you verify it is done and meets quality standards) ### 3. Out of Scope (Exclusions) Explicitly list 5-8 things this project will NOT include, especially items that stakeholders might reasonably assume are included. Format: "This project does not include [item]. Reason: [why]. If needed later: [how to handle it]." ### 4. Assumptions List every assumption the plan depends on. If any of these turn out to be false, the scope, timeline, or budget may need to change. Examples: "The existing content can be migrated without rewriting", "The design agency can start by June 1", "No new features will be added to the current site during the redesign." ### 5. Dependencies Identify external factors that could block progress: | Dependency | Owned By | Needed By | Impact If Delayed | |-----------|----------|-----------|-------------------| ### 6. Milestones and Timeline Break the project into 4-6 phases with dates: | Phase | Key Deliverable | Start Date | End Date | Gate Criteria | |-------|----------------|------------|----------|---------------| Gate criteria define what must be true before the next phase begins. ### 7. Change Request Process A simple 3-step process for handling requests that fall outside this scope document. This prevents informal scope expansion while keeping the project responsive to legitimate needs. ### 8. Risks Top 3-5 risks with likelihood (high/medium/low), impact, and mitigation plan.
Usage Tips
- Write the Out of Scope section first: It is easier to define what you are NOT doing, and it forces the hard conversations early. If a stakeholder pushes back on an exclusion, you have found a misalignment before it becomes expensive.
- Be specific in acceptance criteria: "Website looks good" is not acceptance criteria. "All pages score 90+ on Google PageSpeed Insights and match the approved Figma designs at desktop and mobile breakpoints" is.
- List assumptions you think are obvious: The assumptions that cause the most damage are the ones everyone thinks are self-evident. If you assume the client will provide content by July 1, write it down, because they might assume you are writing it.
- Share the scope document before kickoff: Send it to all stakeholders and ask each one to confirm they have read it. Silence is not agreement. This step takes 10 minutes and prevents weeks of rework.
- Update the document when scope changes: A scope document that does not reflect reality is worse than none. When a change request is approved, update the deliverables, timeline, and any affected assumptions.
Get more from this prompt
Save it, score it with AI, optimize it, and track every version. Free to start.