Project Scoping

Project Scoping

sethdford 5acd531 2 files · 1.4 KB Updated

File contents

Project Scoping

Make boundaries explicit so teams ship the right thing: clear in/out, measurable done, and honest constraints.

When to Use

  • Starting initiatives, reframing slipping timelines, or when “small asks” keep appearing mid-flight.

Workflow

  1. Answer in writing: in scope, out of scope, definition of done, constraints (time, budget, quality, people), and assumptions.
  2. MoSCoW prioritize: Must / Should / Could / Won’t (this version)—especially for feature creep.
  3. Iron triangle reminder: fast, cheap, good—pick the two that are fixed; negotiate the third.
  4. Produce a one-paragraph brief plus success metrics; get explicit sign-off from decision-makers.
  5. Revisit scope when assumptions break (vendor delay, regulation, key hire, etc.) and document changes.

Examples

Example 1: “Just add analytics” mid-project → classify as Should/Could, trade against Must timeline, or phase two with a date.

Example 2: Vague “improve onboarding” → define done (e.g., time-to-first-value, completion rate) and list Won’t items (e.g., no mobile app this quarter).

sethdford/h-uman/tree/main/skill-registry/skills/project-scoping commit 5acd531f1f

Frequently asked questions

npx skillmds@latest add sethdford/project-scoping