pjs-project-scoping

name	pjs - Project Scoping
description	Define project scope — what's included, excluded, success criteria, constraints, and boundaries. Prevents scope creep.
output	{"format":"prose"}

Project Scoping

Input: $ARGUMENTS

---

Overview

Scope creep is the #1 project killer. This procedure forces explicit decisions about what's in and what's out before work begins. A clear scope document becomes the reference for every "should we add X?" conversation.

Steps

Step 1: Define the Objective

1. What is this project trying to achieve? (one sentence)
2. What is the measurable success criterion?
3. Who is the primary beneficiary?
4. Why now? (what triggered this project?)

Step 2: Define What's In Scope

1. List every deliverable explicitly
2. For each deliverable: what does "done" look like?
3. What quality standard applies?
4. What functionality is included?

Step 3: Define What's Out of Scope

This is the critical section. Explicitly list:

1. Features/work that someone might assume is included but isn't
2. Adjacent work that's tempting but not part of this project
3. Future phases (acknowledged but not now)
4. For each exclusion: why it's out, and where it will be addressed (if ever)

Step 4: Identify Constraints

1. Time: hard deadline? Flexible?
2. Budget: fixed? Capped? Flexible?
3. Resources: who's available? What skills?
4. Technical: platform, compatibility, performance requirements
5. Regulatory: compliance, legal requirements

Step 5: Define Boundaries and Change Process

1. What triggers a scope review? (any request that's not in the In Scope list)
2. Who approves scope changes?
3. What's the cost of adding scope? (explicitly: adding X means dropping Y or extending timeline)

Step 6: Document and Align

PROJECT SCOPE
Objective: [one sentence]
Success criterion: [measurable]

IN SCOPE:
1. [deliverable] — Done when: [criteria]
2. [deliverable] — Done when: [criteria]

OUT OF SCOPE:
1. [exclusion] — Why: [reason] — When: [never / phase 2 / separate project]
2. [exclusion] — Why: [reason]

CONSTRAINTS:
- Time: [deadline]
- Budget: [amount]
- Resources: [who/what]

CHANGE PROCESS: [how scope changes are evaluated]

When to Use

• Starting any project
• When scope feels unclear or expanding
• Before committing resources

Verification

• Objective stated in one sentence
• Success criterion is measurable
• In-scope items have "done" criteria
• Out-of-scope items explicitly listed
• Constraints identified
• Change process defined